From nobody Wed May 1 13:08:45 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4C712004F; Wed, 1 May 2019 13:08:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155674131714.1010.2575926473648778016.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2019 13:08:37 -0700 Archived-At: Subject: [lamps] Alissa Cooper's No Objection on charter-ietf-lamps-03-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 20:08:37 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-lamps-03-00: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- s/Specifies a/Specify a/ From nobody Wed May 1 13:14:07 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADCB12011E; Wed, 1 May 2019 13:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfErP-hKsXD8; Wed, 1 May 2019 13:14:03 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 454D41200F4; Wed, 1 May 2019 13:14:03 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x41KDwrZ014607; Wed, 1 May 2019 16:13:58 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x41KDwrZ014607 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1556741639; bh=UtSVNwkJ4ROItoUktJQEs/wnc7jVgEpL/rCBla84o1M=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=nPsyHqvlv7xAarOSFT46IBuxeEJKuw5nm33EyarLpy3XXrg/z1p5s7IZFURwZZlqe awE/DLCdcScpl2l1hVwxpI7qDDYYgtOlQtC5IEvTDbTcreNSg7291Sox5bGMyLl1eo KBgC7lcBdbiHjwT+voTkTk9Mf9IFxZNZclKw4x3M= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x41KDuDm041638; Wed, 1 May 2019 16:13:56 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Wed, 1 May 2019 16:13:56 -0400 From: Roman Danyliw To: Alissa Cooper , The IESG CC: "spasm@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: [lamps] Alissa Cooper's No Objection on charter-ietf-lamps-03-00: (with COMMENT) Thread-Index: AQHVAFmtW46VRnrtE0mx5MEiph0sDqZWs9nA Date: Wed, 1 May 2019 20:13:55 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33513F0@marathon> References: <155674131714.1010.2575926473648778016.idtracker@ietfa.amsl.com> In-Reply-To: <155674131714.1010.2575926473648778016.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Alissa Cooper's No Objection on charter-ietf-lamps-03-00: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 20:14:06 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Alissa Cooper > via Datatracker > Sent: Wednesday, May 01, 2019 4:09 PM > To: The IESG > Cc: spasm@ietf.org; lamps-chairs@ietf.org > Subject: [lamps] Alissa Cooper's No Objection on charter-ietf-lamps-03-00= : > (with COMMENT) >=20 > Alissa Cooper has entered the following ballot position for > charter-ietf-lamps-03-00: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > s/Specifies a/Specify a/ Ooops. This is now fixed in -03-01. Thanks for the feedback. Regards, Roman From nobody Thu May 2 10:04:44 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664F81204ED for ; Thu, 2 May 2019 10:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.797 X-Spam-Level: X-Spam-Status: No, score=-0.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_16=1.092, 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 U_IX6o9z_S_n for ; Thu, 2 May 2019 10:04:41 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 454711204DC for ; Thu, 2 May 2019 10:04:41 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 00A363740843; Thu, 2 May 2019 17:04:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AbMzFQSGuKLQ; Thu, 2 May 2019 13:04:40 -0400 (EDT) Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id D54543740828; Thu, 2 May 2019 13:04:39 -0400 (EDT) To: spasm@ietf.org, Mike Ounsworth References: <155596905782.21170.3345526053472471283.idtracker@ietfa.amsl.com> <4799209C-5C08-4E92-9203-E2A2970AA316@vigilsec.com> <63576812-B7A5-4AA8-A366-DDA3B2ABE59B@vigilsec.com> From: "Dr. Pala" Message-ID: <7cd3ca3d-77a0-906a-8a57-9eb125e8941f@openca.org> Date: Thu, 2 May 2019 11:04:39 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <63576812-B7A5-4AA8-A366-DDA3B2ABE59B@vigilsec.com> Content-Type: multipart/alternative; boundary="------------619791F62AA54250435EEDF1" Content-Language: en-US Archived-At: Subject: Re: [lamps] LAMPS at IETF 105 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 17:04:42 -0000 This is a multi-part message in MIME format. --------------619791F62AA54250435EEDF1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Russ, Tim, all, On the Composite Crypto discussion at the last IETF, I think we will be ready to present on the unified draft proposal that we would like to discuss in LAMPS and, if we are ready, look into asking for adoption of the document. Cheers, Max On 4/23/19 5:10 PM, Russ Housley wrote: > In the last few days before IETF 104, we got a flurry of requests to present in the LAMPS WG. In an effort to learn about them sooner, we are asking whether anyone has topics to discuss in July at IETF 105. The IESG is going through the re-charter process, so we can assume that the header protection work item will be approved by the time that we meet in July. > > Russ & Tim > -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------619791F62AA54250435EEDF1 Content-Type: multipart/related; boundary="------------C1FD10CD5F90915EB915E74B" --------------C1FD10CD5F90915EB915E74B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi Russ, Tim, all,

On the Composite Crypto discussion at the last IETF, I think we will be ready to present on the unified draft proposal that we would like to discuss in LAMPS and, if we are ready, look into asking for adoption of the document.

Cheers,
Max

On 4/23/19 5:10 PM, Russ Housley wrote:
In the last few days before IETF 104, we got a flurry of requests to present in the LAMPS WG.  In an effort to learn about them sooner, we are asking whether anyone has topics to discuss in July at IETF 105.  The IESG is going through the re-charter process, so we can assume that the header protection work item will be approved by the time that we meet in July.

Russ & Tim
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------C1FD10CD5F90915EB915E74B Content-Type: image/png; name="hpohjpcfliakcakn.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="hpohjpcfliakcakn.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= --------------C1FD10CD5F90915EB915E74B-- --------------619791F62AA54250435EEDF1-- From nobody Thu May 2 11:07:36 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236BB120608 for ; Thu, 2 May 2019 11:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUfiKI10njuM for ; Thu, 2 May 2019 11:07:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48CC120617 for ; Thu, 2 May 2019 11:07:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 24A15300ADA for ; Thu, 2 May 2019 13:49:01 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Subirj5_tBO9 for ; Thu, 2 May 2019 13:48:59 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 9B2843005AB; Thu, 2 May 2019 13:48:59 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2D31DB0B-B252-4000-B6DE-78B9152E34FA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 2 May 2019 14:07:16 -0400 In-Reply-To: <7cd3ca3d-77a0-906a-8a57-9eb125e8941f@openca.org> Cc: SPASM , Mike Ounsworth To: "Dr. Pala" References: <155596905782.21170.3345526053472471283.idtracker@ietfa.amsl.com> <4799209C-5C08-4E92-9203-E2A2970AA316@vigilsec.com> <63576812-B7A5-4AA8-A366-DDA3B2ABE59B@vigilsec.com> <7cd3ca3d-77a0-906a-8a57-9eb125e8941f@openca.org> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [lamps] LAMPS at IETF 105 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 18:07:35 -0000 --Apple-Mail=_2D31DB0B-B252-4000-B6DE-78B9152E34FA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Max: Do you believe that the current charter covers you proposed way forward? Russ > On May 2, 2019, at 1:04 PM, Dr. Pala wrote: >=20 > Hi Russ, Tim, all, >=20 > On the Composite Crypto discussion at the last IETF, I think we will = be ready to present on the unified draft proposal that we would like to = discuss in LAMPS and, if we are ready, look into asking for adoption of = the document. >=20 > Cheers, > Max >=20 >=20 > On 4/23/19 5:10 PM, Russ Housley wrote: >> In the last few days before IETF 104, we got a flurry of requests to = present in the LAMPS WG. In an effort to learn about them sooner, we = are asking whether anyone has topics to discuss in July at IETF 105. = The IESG is going through the re-charter process, so we can assume that = the header protection work item will be approved by the time that we = meet in July. >>=20 >> Russ & Tim --Apple-Mail=_2D31DB0B-B252-4000-B6DE-78B9152E34FA Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Max:

Do you believe that the current charter covers you proposed way forward?

Russ


On May 2, 2019, at 1:04 PM, Dr. Pala <madwolf@openca.org> wrote:

Hi Russ, Tim, all,

On the Composite Crypto discussion at the last IETF, I think we will be ready to present on the unified draft proposal that we would like to discuss in LAMPS and, if we are ready, look into asking for adoption of the document.

Cheers,
Max

On 4/23/19 5:10 PM, Russ Housley wrote:
In the last few days before IETF 104, we got a flurry of requests to present in the LAMPS WG.  In an effort to learn about them sooner, we are asking whether anyone has topics to discuss in July at IETF 105.  The IESG is going through the re-charter process, so we can assume that the header protection work item will be approved by the time that we meet in July.

Russ & Tim

--Apple-Mail=_2D31DB0B-B252-4000-B6DE-78B9152E34FA-- From nobody Thu May 2 11:53:53 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F3B120075 for ; Thu, 2 May 2019 11:53:50 -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 dAx5RAkr8YUA for ; Thu, 2 May 2019 11:53:48 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 110AD120004 for ; Thu, 2 May 2019 11:53:48 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id D4B113740876 for ; Thu, 2 May 2019 18:53:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HImi9rEJty-G for ; Thu, 2 May 2019 14:53:46 -0400 (EDT) Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 1F3083740828 for ; Thu, 2 May 2019 14:53:46 -0400 (EDT) To: spasm@ietf.org References: <155596905782.21170.3345526053472471283.idtracker@ietfa.amsl.com> <4799209C-5C08-4E92-9203-E2A2970AA316@vigilsec.com> <63576812-B7A5-4AA8-A366-DDA3B2ABE59B@vigilsec.com> <7cd3ca3d-77a0-906a-8a57-9eb125e8941f@openca.org> From: "Dr. Pala" Message-ID: Date: Thu, 2 May 2019 12:53:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------77FB2064BE172999C455BDDF" Content-Language: en-US Archived-At: Subject: Re: [lamps] LAMPS at IETF 105 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 18:53:51 -0000 This is a multi-part message in MIME format. --------------77FB2064BE172999C455BDDF Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Russ, I was just reviewing it [*] and I do not think it does. I was thinking=20 that if the WG will be interested in the adoption of the document, then=20 we will have to explicitly add a new entry to the list of items in the=20 Charter. I am thinking that the entry might look like the following (but not=20 proposing the re-chartering before the group reviews the combined draft):= Specify the use of composite signatures and keys for PKIX. In recent = years, the crypto communities have been very active in identifying new publi= c key algorithms with different security properties and performances (e.g.,= ECC, Hash-Based, etc.). However, it is not always easy to establish if a n= ew algorithm has been studied enough or if (and when) an old algorithm m= ight fall apart. An example of this uncertainty, today, is related to quan= tum-resistant algorithms vs. "traditional" ones. The possibility for combining algo= rithms with different properties provides support for less risky transitioni= ng strategies for deploying new algorithms by enabling deferred algorithm agility. This is just an example of the required additional item for the charter=20 to get the work in scope, I guess :D Cheers, Max [*] =3D https://datatracker.ietf.org/doc/charter-ietf-lamps/ On 5/2/19 2:07 PM, Russ Housley wrote: > Max: > > Do you believe that the current charter covers you proposed way forward= ? > > Russ > > >> On May 2, 2019, at 1:04 PM, Dr. Pala > > wrote: >> >> Hi Russ, Tim, all, >> >> On the Composite Crypto discussion at the last IETF, I think we will=20 >> be ready to present on the unified draft proposal that we would like=20 >> to discuss in LAMPS and, if we are ready, look into asking for=20 >> adoption of the document. >> >> Cheers, >> Max >> >> On 4/23/19 5:10 PM, Russ Housley wrote: >>> In the last few days before IETF 104, we got a flurry of requests to = present in the LAMPS WG. In an effort to learn about them sooner, we are= asking whether anyone has topics to discuss in July at IETF 105. The IE= SG is going through the re-charter process, so we can assume that the hea= der protection work item will be approved by the time that we meet in Jul= y. >>> >>> Russ & Tim > > > _______________________________________________ > 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 --------------77FB2064BE172999C455BDDF Content-Type: multipart/related; boundary="------------5AF2721970A0BA7FDC91C04A" --------------5AF2721970A0BA7FDC91C04A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Russ,

I was just reviewing it [*] and I do not think it does. I was thinking that if the WG will be interested in the adoption of the document, then we will have to explicitly add a new entry to the list of items in the Charter.

I am thinking that the entry might look like the following (but not proposing the re-chartering before the group reviews the combined draft):

Specify the use of composite signatures and keys for PKIX. In recent years,
the crypto communities have been very active in identifying new public key
algorithms with different security properties and performances (e.g., ECC,
Hash-Based, etc.). However, it is not always easy to establish if a new
algorithm has been studied enough or if (and when) an old algorithm might
fall apart. An example of this uncertainty, today, is related to quantum-resistant
algorithms vs. "traditional" ones. The possibility for combining algorithms
with different properties provides support for less risky transitioning strategies
for deploying new algorithms by enabling deferred algorithm agility.

This is just an example of the required additional item for the charter to get the work in scope, I guess :D

Cheers,
Max


[*] = https://datatracker.ietf.org/doc/charter-ietf-lamps/

On 5/2/19 2:07 PM, Russ Housley wrote:
Max:

Do you believe that the current charter covers you proposed way forward?

Russ


On May 2, 2019, at 1:04 PM, Dr. Pala <madwolf@openca.org> wrote:

Hi Russ, Tim, all,

On the Composite Crypto discussion at the last IETF, I think we will be ready to present on the unified draft proposal that we would like to discuss in LAMPS and, if we are ready, look into asking for adoption of the document.

Cheers,
Max

On 4/23/19 5:10 PM, Russ Housley wrote:
In the last few days before IETF 104, we got a flurry of requests to present in the LAMPS WG.  In an effort to learn about them sooner, we are asking whether anyone has topics to discuss in July at IETF 105.  The IESG is going through the re-charter process, so we can assume that the header protection work item will be approved by the time that we meet in July.

Russ & Tim



_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------5AF2721970A0BA7FDC91C04A Content-Type: image/png; name="nljfehnpngedcfhf.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="nljfehnpngedcfhf.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= --------------5AF2721970A0BA7FDC91C04A-- --------------77FB2064BE172999C455BDDF-- From nobody Thu May 2 12:05:26 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08BA12012C for ; Thu, 2 May 2019 12:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_wYFxaJcHqG for ; Thu, 2 May 2019 12:05:23 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE93120072 for ; Thu, 2 May 2019 12:05:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D9401300AE4 for ; Thu, 2 May 2019 14:47:04 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0vClyiFqTz3r for ; Thu, 2 May 2019 14:47:03 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id E4C1F30024F; Thu, 2 May 2019 14:47:02 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D426DA2D-0635-40E7-8C35-FE06CA0B2907" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 2 May 2019 15:05:19 -0400 In-Reply-To: Cc: SPASM To: "Dr. Pala" References: <155596905782.21170.3345526053472471283.idtracker@ietfa.amsl.com> <4799209C-5C08-4E92-9203-E2A2970AA316@vigilsec.com> <63576812-B7A5-4AA8-A366-DDA3B2ABE59B@vigilsec.com> <7cd3ca3d-77a0-906a-8a57-9eb125e8941f@openca.org> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [lamps] LAMPS at IETF 105 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 19:05:25 -0000 --Apple-Mail=_D426DA2D-0635-40E7-8C35-FE06CA0B2907 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Max: Please start a separate thread, with an appropriate subject line to talk = about the addition to the LAMPS charter that you are suggesting. I do = not want anyone to miss it because of the subject line. Rus > On May 2, 2019, at 2:53 PM, Dr. Pala wrote: >=20 > Hi Russ, >=20 > I was just reviewing it [*] and I do not think it does. I was thinking = that if the WG will be interested in the adoption of the document, then = we will have to explicitly add a new entry to the list of items in the = Charter.=20 >=20 > I am thinking that the entry might look like the following (but not = proposing the re-chartering before the group reviews the combined = draft): >=20 > Specify the use of composite signatures and keys for PKIX. In recent = years, > the crypto communities have been very active in identifying new public = key > algorithms with different security properties and performances (e.g., = ECC, > Hash-Based, etc.). However, it is not always easy to establish if a = new > algorithm has been studied enough or if (and when) an old algorithm = might > fall apart. An example of this uncertainty, today, is related to = quantum-resistant > algorithms vs. "traditional" ones. The possibility for combining = algorithms > with different properties provides support for less risky = transitioning strategies > for deploying new algorithms by enabling deferred algorithm agility. >=20 > This is just an example of the required additional item for the = charter to get the work in scope, I guess :D >=20 > Cheers, > Max >=20 >=20 >=20 > [*] =3D https://datatracker.ietf.org/doc/charter-ietf-lamps/ = > On 5/2/19 2:07 PM, Russ Housley wrote: >> Max: >>=20 >> Do you believe that the current charter covers you proposed way = forward? >>=20 >> Russ >>=20 >>=20 >>> On May 2, 2019, at 1:04 PM, Dr. Pala > wrote: >>>=20 >>> Hi Russ, Tim, all, >>>=20 >>> On the Composite Crypto discussion at the last IETF, I think we will = be ready to present on the unified draft proposal that we would like to = discuss in LAMPS and, if we are ready, look into asking for adoption of = the document. >>>=20 >>> Cheers, >>> Max >>>=20 >>>=20 >>> On 4/23/19 5:10 PM, Russ Housley wrote: >>>> In the last few days before IETF 104, we got a flurry of requests = to present in the LAMPS WG. In an effort to learn about them sooner, we = are asking whether anyone has topics to discuss in July at IETF 105. = The IESG is going through the re-charter process, so we can assume that = the header protection work item will be approved by the time that we = meet in July. >>>>=20 >>>> Russ & Tim >>=20 >>=20 >>=20 >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm = > --=20 > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm --Apple-Mail=_D426DA2D-0635-40E7-8C35-FE06CA0B2907 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Max:

Please start a separate thread, with an appropriate subject line to talk about the addition to the LAMPS charter that you are suggesting.  I do not want anyone to miss it because of the subject line.

Rus


On May 2, 2019, at 2:53 PM, Dr. Pala <madwolf@openca.org> wrote:

Hi Russ,

I was just reviewing it [*] and I do not think it does. I was thinking that if the WG will be interested in the adoption of the document, then we will have to explicitly add a new entry to the list of items in the Charter.

I am thinking that the entry might look like the following (but not proposing the re-chartering before the group reviews the combined draft):

Specify the use of composite signatures and keys for PKIX. In recent years,
the crypto communities have been very active in identifying new public key
algorithms with different security properties and performances (e.g., ECC,
Hash-Based, etc.). However, it is not always easy to establish if a new
algorithm has been studied enough or if (and when) an old algorithm might
fall apart. An example of this uncertainty, today, is related to quantum-resistant
algorithms vs. "traditional" ones. The possibility for combining algorithms
with different properties provides support for less risky transitioning strategies
for deploying new algorithms by enabling deferred algorithm agility.

This is just an example of the required additional item for the charter to get the work in scope, I guess :D

Cheers,
Max


[*] = https://datatracker.ietf.org/doc/charter-ietf-lamps/

On 5/2/19 2:07 PM, Russ Housley wrote:
Max:

Do you believe that the current charter covers you proposed way forward?

Russ


On May 2, 2019, at 1:04 PM, Dr. Pala <madwolf@openca.org> wrote:

Hi Russ, Tim, all,

On the Composite Crypto discussion at the last IETF, I think we will be ready to present on the unified draft proposal that we would like to discuss in LAMPS and, if we are ready, look into asking for adoption of the document.

Cheers,
Max

On 4/23/19 5:10 PM, Russ Housley wrote:
In the last few days before IETF 104, we got a flurry of requests to present in the LAMPS WG.  In an effort to learn about them sooner, we are asking whether anyone has topics to discuss in July at IETF 105.  The IESG is going through the re-charter process, so we can assume that the header protection work item will be approved by the time that we meet in July.

Russ & Tim



_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
<nljfehnpngedcfhf.png>
_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

--Apple-Mail=_D426DA2D-0635-40E7-8C35-FE06CA0B2907-- From nobody Thu May 2 12:55:11 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F912026A for ; Thu, 2 May 2019 12:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_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 eCc2BN6dDjtZ for ; Thu, 2 May 2019 12:55:07 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8961204D6 for ; Thu, 2 May 2019 12:55:07 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 1A6CA374084E for ; Thu, 2 May 2019 19:55:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dtIYQyM5AfSv for ; Thu, 2 May 2019 15:55:06 -0400 (EDT) Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id DF9DB3740828 for ; Thu, 2 May 2019 15:55:05 -0400 (EDT) From: "Dr. Pala" To: spasm@ietf.org References: <155596905782.21170.3345526053472471283.idtracker@ietfa.amsl.com> <4799209C-5C08-4E92-9203-E2A2970AA316@vigilsec.com> <63576812-B7A5-4AA8-A366-DDA3B2ABE59B@vigilsec.com> <7cd3ca3d-77a0-906a-8a57-9eb125e8941f@openca.org> Message-ID: <3d13cd8c-702e-69fe-9ee5-1cfb3f000341@openca.org> Date: Thu, 2 May 2019 13:55:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------BAAB06C6323342D7D9C7824B" Content-Language: en-US Archived-At: Subject: [lamps] Proposed Re-Chartering Text for Composite Crypto Draft (Re: LAMPS at IETF 105) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2019 19:55:10 -0000 This is a multi-part message in MIME format. --------------BAAB06C6323342D7D9C7824B Content-Type: multipart/alternative; boundary="------------BBA37E0808AE74B1C9010E90" --------------BBA37E0808AE74B1C9010E90 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi all, as per Russ request, I am re-posting the message with a more specific Subject (so that people do not miss it) :D ----- ORIGINAL MESSAGE [$] ----- Hi Russ, I was just reviewing the charter [*] and I do not think it supports the Composite Crypto work. I was thinking that if the WG will be interested in the adoption of the document, then we will have to explicitly add a new entry to the list of items in the Charter. From the last meeting, it seemed that there were no major objections to working on this proposal, but no official voting was requested  at that time (it was too early, I think :D). For the charter, I am thinking that the new entry might look like the following (but not proposing the re-chartering before the group reviews the combined draft): Specify the use of composite signatures and keys for PKIX. In recent years, the crypto communities have been very active in identifying new public key algorithms with different security properties and performances (e.g., ECC, Hash-Based, etc.). However, it is not always easy to establish if a new algorithm has been studied enough or if (and when) an old algorithm might fall apart. An example of this uncertainty, today, is related to quantum-resistant algorithms vs. "traditional" ones. The possibility for combining algorithms with different properties provides support for less risky transitioning strategies when deploying new algorithms by enabling deferred algorithm agility. This is just an example of the required additional item for the charter to get the work in scope, I guess :D Please let me know what you think... Cheers, Max [*] = https://datatracker.ietf.org/doc/charter-ietf-lamps/ [$] = Small Editorial changes applied On 5/2/19 2:07 PM, Russ Housley wrote: > Max: > > Do you believe that the current charter covers you proposed way forward? > > Russ > > >> On May 2, 2019, at 1:04 PM, Dr. Pala > > wrote: >> >> Hi Russ, Tim, all, >> >> On the Composite Crypto discussion at the last IETF, I think we will >> be ready to present on the unified draft proposal that we would like >> to discuss in LAMPS and, if we are ready, look into asking for >> adoption of the document. >> >> Cheers, >> Max >> >> On 4/23/19 5:10 PM, Russ Housley wrote: >>> In the last few days before IETF 104, we got a flurry of requests to present in the LAMPS WG. In an effort to learn about them sooner, we are asking whether anyone has topics to discuss in July at IETF 105. The IESG is going through the re-charter process, so we can assume that the header protection work item will be approved by the time that we meet in July. >>> >>> Russ & Tim > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------BBA37E0808AE74B1C9010E90 Content-Type: multipart/related; boundary="------------0C655C30BDA769240744450C" --------------0C655C30BDA769240744450C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi all,

as per Russ request, I am re-posting the message with a more specific Subject (so that people do not miss it) :D

----- ORIGINAL MESSAGE [$] -----

Hi Russ,

I was just reviewing the charter [*] and I do not think it supports the Composite Crypto work. I was thinking that if the WG will be interested in the adoption of the document, then we will have to explicitly add a new entry to the list of items in the Charter. From the last meeting, it seemed that there were no major objections to working on this proposal, but no official voting was requested  at that time (it was too early, I think :D).

For the charter, I am thinking that the new entry might look like the following (but not proposing the re-chartering before the group reviews the combined draft):

Specify the use of composite signatures and keys for PKIX. In recent years,
the crypto communities have been very active in identifying new public key
algorithms with different security properties and performances (e.g., ECC,
Hash-Based, etc.). However, it is not always easy to establish if a new
algorithm has been studied enough or if (and when) an old algorithm might
fall apart. An example of this uncertainty, today, is related to quantum-resistant
algorithms vs. "traditional" ones. The possibility for combining algorithms
with different properties provides support for less risky transitioning strategies
when deploying new algorithms by enabling deferred algorithm agility.

This is just an example of the required additional item for the charter to get the work in scope, I guess :D Please let me know what you think...

Cheers,
Max

[*] = https://datatracker.ietf.org/doc/charter-ietf-lamps/

[$] = Small Editorial changes applied


On 5/2/19 2:07 PM, Russ Housley wrote:
Max:

Do you believe that the current charter covers you proposed way forward?

Russ


On May 2, 2019, at 1:04 PM, Dr. Pala <madwolf@openca.org> wrote:

Hi Russ, Tim, all,

On the Composite Crypto discussion at the last IETF, I think we will be ready to present on the unified draft proposal that we would like to discuss in LAMPS and, if we are ready, look into asking for adoption of the document.

Cheers,
Max

On 4/23/19 5:10 PM, Russ Housley wrote:
In the last few days before IETF 104, we got a flurry of requests to present in the LAMPS WG.  In an effort to learn about them sooner, we are asking whether anyone has topics to discuss in July at IETF 105.  The IESG is going through the re-charter process, so we can assume that the header protection work item will be approved by the time that we meet in July.

Russ & Tim



_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------0C655C30BDA769240744450C Content-Type: image/png; name="nljfehnpngedcfhf.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="nljfehnpngedcfhf.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= --------------0C655C30BDA769240744450C-- --------------BBA37E0808AE74B1C9010E90-- --------------BAAB06C6323342D7D9C7824B Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --------------BAAB06C6323342D7D9C7824B-- From nobody Fri May 3 01:53:04 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991801200D7 for ; Fri, 3 May 2019 01:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmECfomf-7cC for ; Fri, 3 May 2019 01:52:57 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140088.outbound.protection.outlook.com [40.107.14.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC54712006D for ; Fri, 3 May 2019 01:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sv72vzSzWb58oOI9kQw7/lpFhti1cVpSlDGH/Uj3JXA=; b=kTEhu2y9HLVujorG19pvLD+AMX6kCPah+g0w+gTYsWIFpFqYhKqUhB9Z3HcYbSKcynglyza+8NuDnLDFVyFoMHIXps2GxKJizXPybfXwCJXbBY8J+KcM7M1Et9gqT8PoRf+lBynpgLBSsZGHTWLUnDkdMbmwjajuQM4+4CQVScM= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2705.EURPRD10.PROD.OUTLOOK.COM (20.178.202.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Fri, 3 May 2019 08:52:54 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a8f0:4556:8b4a:4342]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::a8f0:4556:8b4a:4342%5]) with mapi id 15.20.1835.018; Fri, 3 May 2019 08:52:54 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" CC: Jim Schaad , Russ Housley , "steffen.fries@siemens.com" Thread-Topic: Follow-up on lightweight CMP profile Thread-Index: AdUBjVaoPCh2rtMkSpWAUH4qEWUaoA== Date: Fri, 3 May 2019 08:52:53 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0deb98b6-e2ac-4336-701e-08d6cfa4bb35 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2705; x-ms-traffictypediagnostic: AM0PR10MB2705: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0026334A56 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(136003)(346002)(376002)(199004)(189003)(53754006)(54896002)(54906003)(6306002)(316002)(52536014)(9686003)(53936002)(74316002)(7736002)(6506007)(6916009)(102836004)(33656002)(5640700003)(55016002)(6436002)(107886003)(4326008)(486006)(186003)(476003)(8676002)(68736007)(26005)(25786009)(81166006)(8936002)(81156014)(1730700003)(71190400001)(71200400001)(14444005)(256004)(66066001)(76116006)(14454004)(478600001)(790700001)(6116002)(5660300002)(3846002)(86362001)(2351001)(2501003)(99286004)(2906002)(73956011)(7696005)(19627235002)(66446008)(64756008)(66556008)(66946007)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2705; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Uhr87x0m9W6325c1wZA/QaF6DH0lFj2MCv9MOd8hxosFFbvF4XRwJ1l/SrfnPXHyMzFJ8jbBWkE3vhG8Y0KikqrqXBgetWh3iQOTO22N/1wEtF0pfxfoYpI8C1sP841hCYE7oMNY0zaQh0owB4cgcs9maB5VyqvkE1Tiy6jIWG89p8aKc8ZJh7tHBSlHlbe6P1cd1Sf5KqwEQsjZIu/oMDe4ycNVZgkItRILRxP4tfwyto2aCfPT6IdV/myjbBsaEnzPzVEjojf+/n95JCZzXYuCg/DQGdn2CXSBxqtBukGgY1J8V14haQnL65chsC6PV1F25Qh/hgHjHqfgKnn9XN3HrZuWPGaeApFMdbRqzUtVMI8x0zLzk2XUD0K42i7cSDcFKpRA8QRorWjks+/8Pupx/5IvN0TKIdxmV9KTuMc= Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24025419EFD95ED54F7D79B5FE350AM0PR10MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0deb98b6-e2ac-4336-701e-08d6cfa4bb35 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2019 08:52:54.0840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2705 Archived-At: Subject: [lamps] Follow-up on lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 08:53:03 -0000 --_000_AM0PR10MB24025419EFD95ED54F7D79B5FE350AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik --_000_AM0PR10MB24025419EFD95ED54F7D79B5FE350AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all

 

Referring to the Email thread '= Seeking guidance on proceeding with question from IETF-104 presentation on = lightweight CMP profile' and to the outcome of the WG meeting, we want to s= ummarize the current state of the discussion.

The discussion we had with Jim = motivate a split of the current draft into a CMP Updates and a CMP Profile = document. The update of CMP is needed because we identified at least two po= int where a change to CMP is needed:

- Change the type of encryptedC= ert from EncryptedValue to EncryptedKey for ECC and post-quantum algorithm = support

- Extend the RootCAUpdate annou= ncement message to e request/response message to enable requesting the upda= te from the client side

The remaining points from the i= nitial email were seen as profiling topic and would therefore be handled in= the CMP Profile document.

 

@Russ, how do you see the statu= s of the current re-chartering process? Would you support to add both, or a= t least the CMP Updates, activities under the revised charter?

 

- Hendrik

--_000_AM0PR10MB24025419EFD95ED54F7D79B5FE350AM0PR10MB2402EURP_-- From nobody Fri May 3 09:35:19 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 787C6120233; Fri, 3 May 2019 09:35:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155690131742.7122.8086237700310456009.idtracker@ietfa.amsl.com> Date: Fri, 03 May 2019 09:35:17 -0700 Archived-At: Subject: [lamps] WG Review: Limited Additional Mechanisms for PKIX and SMIME (lamps) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2019 16:35:18 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-05-13. Limited Additional Mechanisms for PKIX and SMIME (lamps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: spasm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the approach used in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a large-scale quantum computer poses a serious challenge for the key management algorithms that are widely deployed today, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). Hash-based signature use small private and public keys, and they have low computational cost; however, the signature values are quite large. For this reason they might not be used for signing X.509 certificates or S/MIME messages; however, since hash-based signature algorithms are secure even if a large-scale quantum computer is invented. The low computational cost for signature verification makes hash-based signatures attractive in the Internt of Things environments, and the quantum resistance makes them attractive for the distribution of software updates. 6. Specify a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. 7. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. Milestones: Jun 2018 - Adopt a draft for short-lived certificate conventions Jun 2018 - Adopt a draft for the CMS with PSK Jun 2018 - Adopt a draft for hash-based signatures with the CMS Jun 2018 - Adopt a draft for root key rollover certificate extension Jul 2018 - rfc6844bis sent to IESG for standards track publication Aug 2018 - Root key rollover certificate extension sent to IESG for informational publication Sep 2018 - SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018 - SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018 - Short-lived certificate conventions sent to IESG for BCP publication Oct 2018 - The CMS with PSK sent to IESG for standards track publication Dec 2018 - Hash-based signatures with the CMS sent to IESG for standards track publication From nobody Tue May 7 17:18:18 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAF9120254 for ; Tue, 7 May 2019 17:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPzl5bx-pJhM for ; Tue, 7 May 2019 17:18:07 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA4312028B for ; Tue, 7 May 2019 17:18:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4E3E2300AEC for ; Tue, 7 May 2019 19:58:49 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lbof-nZtQi6z for ; Tue, 7 May 2019 19:58:47 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id E792A300474; Tue, 7 May 2019 19:58:46 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F4D423D9-0077-4992-82EB-424E36C9B10F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Tue, 7 May 2019 20:18:03 -0400 In-Reply-To: Cc: "spasm@ietf.org" , Jim Schaad , "steffen.fries@siemens.com" To: "Brockhaus, Hendrik" References: X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [lamps] Follow-up on lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 00:18:17 -0000 --Apple-Mail=_F4D423D9-0077-4992-82EB-424E36C9B10F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hendrik: The current re-charter is about two weeks away. You would need to = propose text for the charter on this list, and see if there are people = that will review and implement. Russ > On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik = wrote: >=20 > Hi all >=20 > =20 >=20 > Referring to the Email thread 'Seeking guidance on proceeding with = question from IETF-104 presentation on lightweight CMP profile' and to = the outcome of the WG meeting, we want to summarize the current state of = the discussion. >=20 > The discussion we had with Jim motivate a split of the current draft = into a CMP Updates and a CMP Profile document. The update of CMP is = needed because we identified at least two point where a change to CMP is = needed: >=20 > - Change the type of encryptedCert from EncryptedValue to EncryptedKey = for ECC and post-quantum algorithm support >=20 > - Extend the RootCAUpdate announcement message to e request/response = message to enable requesting the update from the client side >=20 > The remaining points from the initial email were seen as profiling = topic and would therefore be handled in the CMP Profile document. >=20 > =20 >=20 > @Russ, how do you see the status of the current re-chartering process? = Would you support to add both, or at least the CMP Updates, activities = under the revised charter? >=20 > =20 >=20 > - Hendrik >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_F4D423D9-0077-4992-82EB-424E36C9B10F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hendrik:

The current re-charter is about two weeks away.  You = would need to propose text for the charter on this list, and see if = there are people that will review and implement.

Russ


On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> wrote:

Hi all

 

Referring to the Email thread 'Seeking guidance on proceeding = with question from IETF-104 presentation on lightweight CMP profile' and = to the outcome of the WG meeting, we want to summarize the current state = of the discussion.

The discussion we had with Jim motivate a split of the = current draft into a CMP Updates and a CMP Profile document. The update = of CMP is needed because we identified at least two point where a change = to CMP is needed:

- Change the type of encryptedCert from EncryptedValue to = EncryptedKey for ECC and post-quantum algorithm support

- = Extend the RootCAUpdate announcement message to e request/response = message to enable requesting the update from the client side

The = remaining points from the initial email were seen as profiling topic and = would therefore be handled in the CMP Profile document.

 

@Russ, = how do you see the status of the current re-chartering process? Would = you support to add both, or at least the CMP Updates, activities under = the revised charter?

 

- = Hendrik

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

= --Apple-Mail=_F4D423D9-0077-4992-82EB-424E36C9B10F-- From nobody Wed May 8 02:09:49 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281DD12008D for ; Wed, 8 May 2019 02:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQGTe8jC02iF for ; Wed, 8 May 2019 02:09:44 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40051.outbound.protection.outlook.com [40.107.4.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6473F12001E for ; Wed, 8 May 2019 02:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kfHeaDi0eZHdhvqqtKH6fQrQ1se3Xxnv6HGUN3zgAVg=; b=wa3J3b9PlSLmKeyDwSF9WJy55ugbmLOI2jJ7IFXdMLKsJDNRHWT918htfKgCbkMfZFmCBNueIrMA9rusZNy51cXXbqdDs2eVkGRZzqY5GL68nepN6MNkPAOwVuiM2bO6msvdvdVrNPMkN+Q7bIavTKUHru3UmjcaE0cGEaPTaF8= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2211.EURPRD10.PROD.OUTLOOK.COM (20.177.109.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.20; Wed, 8 May 2019 09:09:41 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1856.012; Wed, 8 May 2019 09:09:41 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" , Russ Housley CC: Jim Schaad , "steffen.fries@siemens.com" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQ== Date: Wed, 8 May 2019 09:09:41 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6cfebfed-0a82-459d-2602-08d6d394e799 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2211; x-ms-traffictypediagnostic: AM0PR10MB2211: x-ms-exchange-purlcount: 1 x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(346002)(376002)(396003)(39860400002)(189003)(199004)(53754006)(110136005)(54906003)(606006)(2501003)(8676002)(33656002)(81166006)(81156014)(7736002)(8936002)(52536014)(66066001)(316002)(2906002)(66556008)(66446008)(64756008)(74316002)(15650500001)(66476007)(76116006)(5660300002)(66946007)(73956011)(2420400007)(478600001)(107886003)(4326008)(486006)(476003)(966005)(186003)(55016002)(7110500001)(6436002)(26005)(54896002)(6306002)(236005)(9686003)(25786009)(99286004)(71200400001)(71190400001)(7696005)(3846002)(6116002)(790700001)(68736007)(86362001)(102836004)(14454004)(256004)(53546011)(6506007)(19627235002)(14444005)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2211; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7TempJk4yRdY45gEpToD3CGOsnmKpW209NTOYaqfzvhU8kFWiVGdbQKfhnyYinp+GCYmJN+00Lx+PC2Nlghxw0U/mIA/CX0gBMRlJZDhUNIe0GDPB6ykBF1VSIsHm/oILaAfXm2v5BTus17p5BIRGTpLIJkAWQ7z3aiYL+ClkU4Dp6cJLJZ/BqlsXkhHT2A514ParGCHIEpzZITUpqJ2mdUfD0wl5iAhFPQ5SSX5ho7VSNfLYyfhiY784C9ju8b1hL8NEqcqNKX6sY3ZmiurGA9V6YNVcHR8nR1jNvpJhtkf3vlDt3zt+DtqQ2R6BEW2/t85qXity8/XezgMhAViloi90EQCkskCbrH+7feH84AcIq0iDp/wxM9pinaKGYHF0jyDLG26Mpg2VbfuA+qHyKYqZ4XoHJw1+OWhgE16XIs= Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24028210BCE560C64195A74EFE320AM0PR10MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cfebfed-0a82-459d-2602-08d6d394e799 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 09:09:41.2438 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2211 Archived-At: Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 09:09:48 -0000 --_000_AM0PR10MB24028210BCE560C64195A74EFE320AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) Cc: spasm@ietf.org; Jim Schaad ; Fries, Steffen (CT= RDA ITS) Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_AM0PR10MB24028210BCE560C64195A74EFE320AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ, = all,

&nbs= p;

as discussed at IETF104 and on this list we would like to spend furth= er work on updating and profiling CMP focusing on industrial use cases.

To get input, feedback and support from LAMPS we propose the followin= g charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>= ;
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@sie= mens.com>
Cc: spasm@ietf.org; Jim Schaad <ietf@augustcellars.com>; Fries= , Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 



On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.c= om> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= .

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

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

 

--_000_AM0PR10MB24028210BCE560C64195A74EFE320AM0PR10MB2402EURP_-- From nobody Wed May 8 04:05:20 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7E7120094 for ; Wed, 8 May 2019 04:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=asvsyzyw; dkim=pass (1024-bit key) header.d=primekey.com header.b=asvsyzyw 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 ZtdwSZwQGxaZ for ; Wed, 8 May 2019 04:05:16 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00B1612003E for ; Wed, 8 May 2019 04:05:15 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 182946AA0090 for ; Wed, 8 May 2019 13:05:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1557313510; bh=TERkS9tkH1nY0LjDzDDcjg4ERgFvnow+grCXdTdMQ9o=; h=Subject:To:References:From:Date:In-Reply-To:From; b=asvsyzywyvL0EuQrCLEZQtMwrqPAwhXTgatIuVnFbhhc2a9SOYg1zJKtFphVRcae0 ZFjqO+AQ9oBZzl84MOg23iARSaK9SLEoU9O/m8oDHEskJ7osouau33/adwdRMhBG+/ C4LZrmacT0nJKqn4azMDmZemcjCSNOyXPYoNtu+0= Received: from [192.168.43.22] (unknown [94.234.44.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 916B36AA008C for ; Wed, 8 May 2019 13:05:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1557313510; bh=TERkS9tkH1nY0LjDzDDcjg4ERgFvnow+grCXdTdMQ9o=; h=Subject:To:References:From:Date:In-Reply-To:From; b=asvsyzywyvL0EuQrCLEZQtMwrqPAwhXTgatIuVnFbhhc2a9SOYg1zJKtFphVRcae0 ZFjqO+AQ9oBZzl84MOg23iARSaK9SLEoU9O/m8oDHEskJ7osouau33/adwdRMhBG+/ C4LZrmacT0nJKqn4azMDmZemcjCSNOyXPYoNtu+0= To: spasm@ietf.org References: <153919524373.5861.7228296681722124369.idtracker@ietfa.amsl.com> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <9630953f-b7d3-3cc2-8fc6-e01738905bd3@primekey.com> Date: Wed, 8 May 2019 13:05:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 11:05:19 -0000 Hi, I support this initiative/re-charter. Regards, Tomas Gustavsson PrimeKey Solutions AB --- Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further work on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following charter text. As certificate management gets increasingly important in industrial environments, it needs to be tailored to the specific needs. CMP as existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be enhanced to more efficiently support of industrial use cases, crypto agility and specific communication relations on the one hand and profiled to the necessary functionality on the other hand to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley ; Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) ; Cc: spasm@ietf.org; Jim Schaad ;; Fries, Steffen (CT RDA ITS) ; Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose text for the charter on this list, and see if there are people that will review and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile' and to the outcome of the WG meeting, we want to summarize the current state of the discussion. The discussion we had with Jim motivate a split of the current draft into a CMP Updates and a CMP Profile document. The update of CMP is needed because we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response message to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic and would therefore be handled in the CMP Profile document. @Russ, how do you see the status of the current re-chartering process? Would you support to add both, or at least the CMP Updates, activities under the revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Wed May 8 07:00:26 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C6612011C for ; Wed, 8 May 2019 07:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eneNO0rV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=E33TvTrY 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 qA376VpzYxRq for ; Wed, 8 May 2019 07:00:21 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 820F8120089 for ; Wed, 8 May 2019 07:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15840; q=dns/txt; s=iport; t=1557324021; x=1558533621; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Bu0c0mWE/EpBZkRe4SWHifmj3H43aY/rPAC8mLXi77I=; b=eneNO0rVP9a9pdev18JNWcYYCgxno9DqV7ljh/5Y/2IandQzcj6zW7cd UNjvNmjYSu0Bwo7cyL8qd3YZ1WG3Hu2fJRKaRovV03WQO3jUdEUREQqNc eRmrbT9q7JKhXlOQ0fNyC7QJPF0SqPsJNFHRKMQIC5wasxmNPJz05Brn2 U=; IronPort-PHdr: =?us-ascii?q?9a23=3ApoRNABY3raHzZWIXvcifQIr/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABG4NJc/5tdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgQ4vJCwDaVUgBAsoh1cDjn2CV5JXhE2?= =?us-ascii?q?BLhSBEANUCQcBARgBCQsCgQRdgl4CgggjNgcOAQMBAQQBAQIBBG0cDIVKAQE?= =?us-ascii?q?BBAEBEBsTAQEsBAcBDwIBCBEEAQEkBAcnCxQJCAEBBAENBQgagnsEAoEdTQM?= =?us-ascii?q?dAQ6iBgKBNYhfgiCCeQEBBYR8AxWCDgMGgTIBigqBQxeBQD+BEUaCHi4+gmE?= =?us-ascii?q?BAQIYgQsJARIBISsJgwaCBCKLHBEkhlaICY0WCQKCCYYdjE2CEJNHiGqDOoE?= =?us-ascii?q?hk1UCBAIEBQIOAQEFgVUBMQ1YcXAVO4JsE4FYJDeDOIUUhT9yAQEBAYEljSO?= =?us-ascii?q?BVG8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,446,1549929600"; d="scan'208,217";a="268815643" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 May 2019 14:00:20 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x48E0KnR026314 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 May 2019 14:00:20 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 May 2019 09:00:19 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 May 2019 09:00:17 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 8 May 2019 09:00:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rve7vHAfJ2S1/wgRCFAX5zlLiieKAh0yCm0/uZZjpmA=; b=E33TvTrYKMnS2kok0iNSS3DDNmudNYNRN5qDNVbK6VBOradHQjK7IHiOw9Wk1tEFXIZBXhkTYu2TVz0k0ElIRrXU6iOOR2kjwsbwUzLJ4lGNg4ixb7ltgY79bgAdG9SZUvO2eEalcC6xfQxDgTNDDn1HCz49nbubgOZYVXUq/Ms= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (10.175.53.141) by MWHPR11MB1344.namprd11.prod.outlook.com (10.169.232.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Wed, 8 May 2019 14:00:15 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::4964:5495:9121:8f12]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::4964:5495:9121:8f12%7]) with mapi id 15.20.1878.019; Wed, 8 May 2019 14:00:15 +0000 From: "Panos Kampanakis (pkampana)" To: "spasm@ietf.org" , Russ Housley , "Brockhaus, Hendrik" CC: Jim Schaad , "steffen.fries@siemens.com" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZw Date: Wed, 8 May 2019 14:00:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1006::f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3fe00d9d-7a30-447f-e053-08d6d3bd7f17 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MWHPR11MB1344; x-ms-traffictypediagnostic: MWHPR11MB1344: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(376002)(346002)(136003)(199004)(53754006)(189003)(33656002)(46003)(76176011)(74316002)(68736007)(53936002)(102836004)(6506007)(55016002)(71190400001)(790700001)(186003)(316002)(71200400001)(6116002)(236005)(15650500001)(6436002)(2420400007)(14444005)(256004)(446003)(606006)(229853002)(73956011)(9686003)(476003)(486006)(6306002)(54896002)(7736002)(11346002)(53546011)(2906002)(25786009)(8676002)(8936002)(5660300002)(966005)(478600001)(9326002)(99286004)(14454004)(66446008)(110136005)(6246003)(81166006)(76116006)(4326008)(52536014)(81156014)(66556008)(66476007)(2501003)(7110500001)(54906003)(7696005)(64756008)(86362001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1344; H:MWHPR11MB1838.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zjjmc8+gC3kWwmsEuzpzTvLn2sxD+ZseB85Sa6fvihGHpWdxWDLZAX2RGrprJXeO+C/Wj072OW/1ogFOryF/xhMX83ugIJVMHZgBZ7C61tcjMsu3N2qcdhEtAOLmxhXeQZPKe5kqsOOgJR3O8WuWhYtSwl23mpZ4Tqo6sD9jE2eAxmSFGDOV5lpue89P4Q6zZJfIu1EGbOVLZ9McMZjmeVv1aaAuNk1UtEP77YXg9x8FNEHFFKmGyE04+9gGEa32MxAC9BCtfxy81lw+wMgAd+21QEwNNbWJkCKE5UXTjh0qV0WGpW0Wp102dSbrgyokunzvtzrovFUX1nzd4WtLMLT0m1et4yqhW4q9j0WJ2txDJimeBqJk6szeyUwKK5vj8Rl/JpOYzT9uBRV0XdkKDf1lAqt6456k6jxLMnAgMP0= Content-Type: multipart/alternative; boundary="_000_MWHPR11MB1838E6295E39B04C0591DC28C9320MWHPR11MB1838namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3fe00d9d-7a30-447f-e053-08d6d3bd7f17 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 14:00:15.2103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1344 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 14:00:25 -0000 --_000_MWHPR11MB1838E6295E39B04C0591DC28C9320MWHPR11MB1838namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm On Behalf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley Cc: Jim Schaad ; steffen.fries@siemens.com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_MWHPR11MB1838E6295E39B04C0591DC28C9320MWHPR11MB1838namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi Hendrik,=

 

Long time since we tal= ked.

 

With such a profile, I= have a concern that what happened with SCEP, CMC, CMPv2, EST is likely to = happen in constrained environments. Using two or more protocols (EST-coaps,= a CMP profile over different transports, and others) that do similar things would lead to fragmentation and confuse= vendors that want to pick one.

 

I am not sure I have h= eard a broad need for a CMP profile in ACE. If this is a single vendor need= , does IETF even need to standardize this CMP profile?

 

Panos

 

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housley <housley@vigilsec.com>
Cc: Jim Schaad <ietf@augustcellars.com>; steffen.fries@siemens= .com
Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on this list we would li= ke to spend further work on updating and profiling CMP focusing on industri= al use cases.

To get input, feedback and support from LAMPS we pro= pose the following charter text.

 

= As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in industrial environments it needs to be enhanced to more e= fficiently support of industrial use cases, crypto agility and specific com= munication relations on the one hand and profiled to the necessary function= ality on the other hand to ease application and to better facilitate interoperable implementation. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilse= c.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about tw= o weeks away.  You would need to propose text for the charter on this = list, and see if there are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockh= aus, Hendrik <hendrik.b= rockhaus@siemens.com> wrote:

 

Hi= all

&n= bsp;

Re= ferring to the Email thread 'Seeking guidance on proceeding with question f= rom IETF-104 presentation on lightweight CMP profile' and to the outcome of= the WG meeting, we want to summarize the current state of the discussion.

Th= e discussion we had with Jim motivate a split of the current draft into a C= MP Updates and a CMP Profile document. The update of CMP is needed because = we identified at least two point where a change to CMP is needed:

- = Change the type of encryptedCert from EncryptedValue to EncryptedKey for EC= C and post-quantum algorithm support

- = Extend the RootCAUpdate announcement message to e request/response message = to enable requesting the update from the client side=

Th= e remaining points from the initial email were seen as profiling topic and = would therefore be handled in the CMP Profile document..<= o:p>

&n= bsp;

@R= uss, how do you see the status of the current re-chartering process? Would = you support to add both, or at least the CMP Updates, activities under the = revised charter?

&n= bsp;

- = Hendrik

______________________________________= _________
Spasm mailing list
= Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

 

--_000_MWHPR11MB1838E6295E39B04C0591DC28C9320MWHPR11MB1838namp_-- From nobody Wed May 8 07:54:16 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEA6120296 for ; Wed, 8 May 2019 07:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZG7-gKJTQn6 for ; Wed, 8 May 2019 07:54:03 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130090.outbound.protection.outlook.com [40.107.13.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F8F1202BF for ; Wed, 8 May 2019 07:54:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1XUpcvlmaVPEAnswT1nKiXCUitvnKbnD8m+kpvIDvkQ=; b=E8I2XrOOgiIbWXaI6zMJct9+MCStjlLqSqNFJMtALUv8A62XkU92TJ+/yMpwHAYtqOEigHaFAQ6AF/gPMHnEo9TakV1tlRinUPBVoZcfRNKHNE8xiSzNCXPUd6E+B4jUGbT4ZPIw0s/lAO4A4Jiu6SoJozjHMCEbseM5Y1Wsk/8= Received: from HE1PR0701MB2444.eurprd07.prod.outlook.com (10.168.130.8) by HE1PR0701MB2473.eurprd07.prod.outlook.com (10.168.125.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.19; Wed, 8 May 2019 14:53:59 +0000 Received: from HE1PR0701MB2444.eurprd07.prod.outlook.com ([fe80::4457:ee7d:f295:6ceb]) by HE1PR0701MB2444.eurprd07.prod.outlook.com ([fe80::4457:ee7d:f295:6ceb%9]) with mapi id 15.20.1878.019; Wed, 8 May 2019 14:53:59 +0000 From: "Peylo, Martin (Nokia - FI/Espoo)" To: "Panos Kampanakis (pkampana)" , "spasm@ietf.org" , Russ Housley , "Brockhaus, Hendrik" CC: Jim Schaad , "steffen.fries@siemens.com" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAACRFEA= Date: Wed, 8 May 2019 14:53:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=martin.peylo@nokia.com; x-originating-ip: [131.228.2.11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 04581b45-290b-4f6d-b638-08d6d3c500be x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:HE1PR0701MB2473; x-ms-traffictypediagnostic: HE1PR0701MB2473: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(136003)(366004)(189003)(199004)(52314003)(53754006)(14454004)(2501003)(25786009)(54906003)(110136005)(2906002)(81166006)(229853002)(7736002)(446003)(15650500001)(2420400007)(8676002)(81156014)(476003)(486006)(8936002)(11346002)(236005)(6436002)(55016002)(606006)(33656002)(9686003)(6306002)(54896002)(508600001)(316002)(71200400001)(26005)(6246003)(76176011)(68736007)(52536014)(76116006)(7110500001)(66066001)(102836004)(71190400001)(66946007)(66556008)(53546011)(6506007)(186003)(73956011)(966005)(66476007)(64756008)(74316002)(66446008)(256004)(14444005)(53936002)(6116002)(4326008)(7696005)(3846002)(790700001)(99286004)(86362001)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2473; H:HE1PR0701MB2444.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jyxXj+VZjG/FrabU8PvTOUv5O9SYPO3Vxi3Co+Qz377uS0I0HTAvcJAr6IniZ45bd8ZCzxq6Q1hxfx4AwuvGA2aMlC61ILHHfg6RgEHnCypvUItQQyRZGlRqJ4+VHhNrCJJ/UJleMzq/9WuLB0cnr/zAm94IRblR2EkTIm3Wk3Ra/2E5kQY+3XNSJGAXSNIEIUhCgbqPn5fnN1+ATVL1qbkQ0OpjL4uhbCPU5WWPUgSYoNY+AqnRMVJS9NB1TmMrvtulOiGObSrpen0dAxydfb61bO9hNKe9kQwnugsZrYGPRxVx5lbZGiyhecma2cw668i3iMwuwxq3yngWvBBX531+3WwDKZSMEv0TEEQMisd8s06G2pgvziq6ENk62tyzIOrJ5vlSFOERF/6Zp1LbLIxzD4omZqBsLPll5axbIP0= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB244401CFEC4F4006C7FD443D9B320HE1PR0701MB2444_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 04581b45-290b-4f6d-b638-08d6d3c500be X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 14:53:59.2879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2473 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 14:54:15 -0000 --_000_HE1PR0701MB244401CFEC4F4006C7FD443D9B320HE1PR0701MB2444_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I see good value of clear CMP profiles for different use cases. The actual problem why CMP isn't as widely used as it could be is that it a= ims to cater for every possible and impossible use case. RFC 4210, Appendix= D certainly has room for improvement; To be conformant, implementers need = to add features very few users would actually want to use, e.g. the second = CertReqMsg in an IR. The plethora of options certainly is the main issue fo= r implementing with wide interworking - there are e.g. multiple meaningful = ways to implement RA-CA communications. So, clear CMP profiles will be a va= luable tool for implementers to provide interoperable clients and servers f= or defined use cases. Panos, I haven't followed ACE lately, but I could imagine that also users o= f the work currently done in ACE could benefit from this. CMP caters very w= ell for the needs of RA-CA communications, and there are many scenarios whe= re PKIs for constrained devices benefit from utilizing RAs. So, also a clea= r profile for RA-CA communication would certainly be a benefit the constrai= ned-device world, even if it is not directly visible on the constrained dev= ices themselves. But anyway, it appears quite possible to shrink a CMP implementation for a = constrained device. As a PoC, I have implemented a rudimentary CMP client [= 1] for Mbed(tm) in 2017. As minimal profile, I basically did IR with MSG_SI= G_ALG and implicit confirm - that worked well on a FRDM-K64F. A careful update for RFC 4210 should also allow to refresh the list of mand= atory algorithms, not least putting SHA-1 and 3-DES to rest. I'm looking forward to discussing details of profiles and other enhancement= s to the protocol specification. Cheers, Martin [1] https://github.com/nokia/CMPclient-embedded-lib From: Spasm On Behalf Of Panos Kampanakis (pkampan= a) Sent: Wednesday, May 8, 2019 5:00 PM To: spasm@ietf.org; Russ Housley ; Brockhaus, Hendrik= Cc: Jim Schaad ; steffen.fries@siemens.com Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens..com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_HE1PR0701MB244401CFEC4F4006C7FD443D9B320HE1PR0701MB2444_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

&nbs= p;

I see good value of clear CMP profiles for different use cases.

 

The actual problem why CMP isn’t as widely used as it could be = is that it aims to cater for every possible and impossible use case. RFC 42= 10, Appendix D certainly has room for improvement; To be conformant, implementers need to add features very few users would a= ctually want to use, e.g. the second CertReqMsg in an IR. The plethora of o= ptions certainly is the main issue for implementing with wide interworking = – there are e.g. multiple meaningful ways to implement RA-CA communications. So, clear CMP profiles will be a v= aluable tool for implementers to provide interoperable clients and servers = for defined use cases.

 

Panos, I haven’t followed ACE lately, but I could imagine that = also users of the work currently done in ACE could benefit from this. CMP c= aters very well for the needs of RA-CA communications, and there are many scenarios where PKIs for constrained devices benefit fr= om utilizing RAs. So, also a clear profile for RA-CA communication would ce= rtainly be a benefit the constrained-device world, even if it is not direct= ly visible on the constrained devices themselves.

 

But anyway, it appears quite possible to shrink a CMP implementation = for a constrained device. As a PoC, I have implemented a rudimentary CMP cl= ient [1] for Mbed™ in 2017. As minimal profile, I basically did IR with MSG_SIG_ALG and implicit confirm – = that worked well on a FRDM-K64F.

 

A careful update for RFC 4210 should also allow to refresh the list o= f mandatory algorithms, not least putting SHA-1 and 3-DES to rest.

 

I’m looking forward to discussing details of profiles and other= enhancements to the protocol specification.

 

Cheers,

Martin

 

 

[1] https://github.com/nokia/CMPclient-embedded-lib

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, May 8, 2019 5:00 PM
To: spasm@ietf.org; Russ Housley <housley@vigilsec.com>; Brock= haus, Hendrik <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@augustcellars.com>; steffen.fries@siemens= .com
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

&n= bsp;

Hi Hend= rik,

&n= bsp;

Long ti= me since we talked.

&n= bsp;

With su= ch a profile, I have a concern that what happened with SCEP, CMC, CMPv2, ES= T is likely to happen in constrained environments. Using two or more protoc= ols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation= and confuse vendors that want to pick one.

&n= bsp;

I am no= t sure I have heard a broad need for a CMP profile in ACE. If this is a sin= gle vendor need, does IETF even need to standardize this CMP profile?<= /o:p>

&n= bsp;

Panos

&n= bsp;

&n= bsp;

 

Hi Russ, all,

 

as discussed at IETF104 and on = this list we would like to spend further work on updating and profiling CMP= focusing on industrial use cases.

To get input, feedback and supp= ort from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilse= c.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about tw= o weeks away.  You would need to propose text for the charter on this = list, and see if there are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockh= aus, Hendrik <hendrik.b= rockhaus@siemens.com> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:<= o:p>

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ..

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

______________________________________= _________
Spasm mailing list
= Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

 

--_000_HE1PR0701MB244401CFEC4F4006C7FD443D9B320HE1PR0701MB2444_-- From nobody Wed May 8 08:02:45 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49E6120123 for ; Wed, 8 May 2019 08:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHr0JRiiUlxk for ; Wed, 8 May 2019 08:02:30 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70059.outbound.protection.outlook.com [40.107.7.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1040C12012B for ; Wed, 8 May 2019 08:02:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b+A//W2maa4pFe4bxxL8Hn8agi03lvcp8tTN+D/e2iU=; b=2RI+QrksVpEKOPPdg0EZdz0ngyDHWbfaTTvSC5cGq4VI5nAoTYGGwfkmgJol1wUTRp6dz2I3RKYSWebM/6QeycknNRej56/v89gonVDXGo6aAeGOvE/b3mlTflqszxeeiiHMrNhSgI28kFZYGDFa7JoWw91GR5GbsoAYHavvRL0= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2340.EURPRD10.PROD.OUTLOOK.COM (20.177.111.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.11; Wed, 8 May 2019 15:02:19 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1856.012; Wed, 8 May 2019 15:02:18 +0000 From: "Brockhaus, Hendrik" To: "Panos Kampanakis (pkampana)" , "spasm@ietf.org" CC: Jim Schaad , Russ Housley , "steffen.fries@siemens.com" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAAIqrYA= Date: Wed, 8 May 2019 15:02:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 653a9a88-3b5c-411b-3685-08d6d3c62a86 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2340; x-ms-traffictypediagnostic: AM0PR10MB2340: x-ms-exchange-purlcount: 1 x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0031A0FFAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(136003)(39860400002)(396003)(199004)(189003)(53754006)(186003)(256004)(14444005)(6116002)(25786009)(790700001)(7110500001)(107886003)(4326008)(2501003)(8936002)(71200400001)(71190400001)(74316002)(8676002)(606006)(15650500001)(476003)(316002)(5660300002)(52536014)(446003)(66066001)(64756008)(66476007)(66556008)(26005)(53936002)(11346002)(81156014)(66446008)(66946007)(76116006)(73956011)(81166006)(6436002)(7736002)(236005)(9686003)(3846002)(2906002)(54896002)(6306002)(55016002)(486006)(2420400007)(110136005)(76176011)(33656002)(7696005)(14454004)(19627235002)(54906003)(86362001)(99286004)(6506007)(53546011)(102836004)(478600001)(68736007)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2340; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: QQWM+mJslUykeCtEuFC5Ib/hOtFHpnE893a+sFor4zjwnd6YNV2MJ7rMjzauJ3vS/PyfUWuV6oJNj4G8SH5FzCJdX74tTR8THrtuxOO6euuWRH3llBgAXA7spKCSBNxZ5yyOE88TjmITlAjhevl+ZnD8hU0659hwDl/G05/1F8Jc9CP7sQVvxmTXxsMvppLxf/F0ojrE9hYNtowoh1fqv42+VeHCHgzh9m4Nl0h8vlP01QQFaFWF70T6EmoHs3sR2PkfAF6OGFylV+gIkPDsI5Ww8b/PRYucE+NcDcgmXgkUuBK8QNWrTtkB1gtByfdZb28tFjwOLs6oUJaanQKRSyIE2qe8Kff9hLKSwx91fylCe2V1DEn5SxhJmNZHOXyCWLrSkHVqW2AfAO1GFGQf5/sLU1eZm84dm5fsJsN1WbE= Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24028EE38E0E50BA6B30BC05FE320AM0PR10MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 653a9a88-3b5c-411b-3685-08d6d3c62a86 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2019 15:02:18.9498 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2340 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 15:02:34 -0000 --_000_AM0PR10MB24028EE38E0E50BA6B30BC05FE320AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Panos, missed you in Prague. Steffen had a discussion on the focus of our CMP profile with Jim after the= ACE meeting in Prague. May be we did not focus enough on industrial use ca= ses. Our focus in not in the first place on constrained devices, but we bel= ieve that CMP would also work perfectly on all those devices capable to run= TLS. Currently CMP is already used in mobile networks and in rail networks. But = we see the need to specify the needed uses cases in more detail to get inte= roperable implementations. The big advantage of CMP for industrial use is that we do not have any secu= rity requirements to the transport of the messages, since CMP messages are = self-contained and support end-to-end security. A hop-by-hop security or a= synchronous transport is not always feasible. Hendrik Von: Panos Kampanakis (pkampana) Gesendet: Mittwoch, 8. Mai 2019 16:00 An: spasm@ietf.org; Russ Housley ; Brockhaus, Hendrik= (CT RDA ITS SEA-DE) Cc: Jim Schaad ; Fries, Steffen (CT RDA ITS) Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens.com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_AM0PR10MB24028EE38E0E50BA6B30BC05FE320AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Panos,=

&nbs= p;

missed yo= u in Prague.

&nbs= p;

Steffen had a discussion on the focus of our CMP profile with Jim aft= er the ACE meeting in Prague. May be we did not focus enough on industrial = use cases. Our focus in not in the first place on constrained devices, but we believe that CMP would also work perf= ectly on all those devices capable to run TLS.

Currently CMP is already used in mobile networks and in rail networks= . But we see the need to specify the needed uses cases in more detail to ge= t interoperable implementations.

The big advantage of CMP for industrial use is that we do not have an= y security requirements to the transport of the messages, since CMP message= s are self-contained and support end-to-end security.  A hop-by-hop security or asynchronous transport is not alw= ays feasible.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampana= @cisco.com>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm@ietf.org; Russ Housley <housley@vigilsec.com>; Brock= haus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RD= A ITS) <steffen.fries@siemens.com>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

&n= bsp;

Hi Hend= rik,

&n= bsp;

Long ti= me since we talked.

&n= bsp;

With su= ch a profile, I have a concern that what happened with SCEP, CMC, CMPv2, ES= T is likely to happen in constrained environments. Using two or more protoc= ols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation= and confuse vendors that want to pick one.

&n= bsp;

I am no= t sure I have heard a broad need for a CMP profile in ACE. If this is a sin= gle vendor need, does IETF even need to standardize this CMP profile?<= /o:p>

&n= bsp;

Panos

&n= bsp;

&n= bsp;

From: Spasm <spasm-bounc= es@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; steffen.fries@siemens.com<= br> Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on = this list we would like to spend further work on updating and profiling CMP= focusing on industrial use cases.

To get input, feedback and supp= ort from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.c= om> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ..

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

_______________________________________________ Spasm mailing list
Spasm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spasm

 

--_000_AM0PR10MB24028EE38E0E50BA6B30BC05FE320AM0PR10MB2402EURP_-- From nobody Wed May 8 16:12:38 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4926B1201AE for ; Wed, 8 May 2019 16:12:35 -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 NQXogtnIpOQb for ; Wed, 8 May 2019 16:12:31 -0700 (PDT) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id A74181201A8 for ; Wed, 8 May 2019 16:12:31 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 656493740EE4 for ; Wed, 8 May 2019 23:12:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id byecrKFdFNeo for ; Wed, 8 May 2019 19:12:19 -0400 (EDT) Received: from Maxs-MBP.cablelabs.com (unknown [192.160.73.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 88EEC3740E7B for ; Wed, 8 May 2019 19:12:19 -0400 (EDT) To: spasm@ietf.org References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Wed, 8 May 2019 17:12:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6D52ED8AA17D9AC797A7DD10" Content-Language: en-US Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 23:12:35 -0000 This is a multi-part message in MIME format. --------------6D52ED8AA17D9AC797A7DD10 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Hendrik, all, I too support this effort and I have few use-cases that might be relevant= =2E First of all, this work is something I needed to do for the EAP-CREDS=20 (Credentials Management over EAP) work (we need a simplified profile for = the EAP-CREDS to work :D). Another important use case we have is related to medical devices (we=20 have been working with CMI for a while now): in that environment we need = to use reasonably-lived certificates (not the usual 20yrs device cert)=20 with frequent renewals: when trying to select a simple protocol, CMP=20 seemed the right choice over others because of its ease of=20 implementation and flexibility. Another use-case is within Wireless Broadband Alliance (WBA) - there, we = are working to define and deploy a RadSec-only deployment for a=20 WBA-centric roaming infrastructure, and part of that work is to define=20 how to deliver server-side (but, in the future, also client-side via=20 EAP-CREDS :D) certificates. We are also evaluating the deployment of the same (or very similar)=20 approach for the DOCSIS(r) standard (Cable Networks). I also want to point out that CMP is already used in 3gpp (the very=20 basic version) in their SIM-based (only for an initial authentication)=20 certificate provisioning system (well, just the very basic of the=20 protocol here). Last but not least, I do like CMP because it allows me to use it=20 independently from the transport protocol, which is a huge win for me=20 (e.g., when granting access to the network and connectivity is not there = yet, I want to be able to provision/manage the credentials even before=20 the device goes online). Something like ACME, for example, it is=20 completely useless for all my use-cases (and super inefficient :D). I will be happy to provide my input for the work, if needed :D Just my 2 cents... Cheers, Max On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote: > > Hi Panos, > > missed you in Prague. > > Steffen had a discussion on the focus of our CMP profile with Jim=20 > after the ACE meeting in Prague. May be we did not focus enough on=20 > industrial use cases. Our focus in not in the first place on=20 > constrained devices, but we believe that CMP would also work perfectly = > on all those devices capable to run TLS. > > Currently CMP is already used in mobile networks and in rail=20 > networks.. But we see the need to specify the needed uses cases in=20 > more detail to get interoperable implementations. > > The big advantage of CMP for industrial use is that we do not have any = > security requirements to the transport of the messages, since CMP=20 > messages are self-contained and support end-to-end security. =A0A=20 > hop-by-hop security or asynchronous transport is not always feasible. > > Hendrik > > *Von:* Panos Kampanakis (pkampana) > *Gesendet:* Mittwoch, 8. Mai 2019 16:00 > *An:* spasm@ietf.org; Russ Housley ; Brockhaus,=20 > Hendrik (CT RDA ITS SEA-DE) > *Cc:* Jim Schaad ; Fries, Steffen (CT RDA ITS) = > > *Betreff:* RE: Proposed Re-Chartering Text for CMP updates and=20 > lightweight profile (RE: Follow-up on lightweight CMP profile) > > Hi Hendrik, > > Long time since we talked. > > With such a profile, I have a concern that what happened with SCEP,=20 > CMC, CMPv2, EST is likely to happen in constrained environments. Using = > two or more protocols (EST-coaps, a CMP profile over different=20 > transports, and others) that do similar things would lead to=20 > fragmentation and confuse vendors that want to pick one. > > I am not sure I have heard a broad need for a CMP profile in ACE. If=20 > this is a single vendor need, does IETF even need to standardize this=20 > CMP profile? > > Panos > > *From:*Spasm >=20 > *On Behalf Of *Brockhaus, Hendrik > *Sent:* Wednesday, May 08, 2019 5:10 AM > *To:* spasm@ietf.org ; Russ Housley=20 > > > *Cc:* Jim Schaad >; steffen.fries@siemens.com=20 > > *Subject:* [lamps] Proposed Re-Chartering Text for CMP updates and=20 > lightweight profile (RE: Follow-up on lightweight CMP profile) > > Hi Russ, all, > > as discussed at IETF104 and on this list we would like to spend=20 > further work on updating and profiling CMP focusing on industrial use=20 > cases. > > To get input, feedback and support from LAMPS we propose the following = > charter text. > > As certificate management gets increasingly important in industrial=20 > environments, it needs to be tailored to the specific needs. CMP as=20 > existing protocol offers a vast range of options. As it is already=20 > being applied in industrial environments it needs to be enhanced to=20 > more efficiently support of industrial use cases, crypto agility and=20 > specific communication relations on the one hand and profiled to the=20 > necessary functionality on the other hand to ease application and to=20 > better facilitate interoperable implementation. > > Hendrik > > *Von:* Russ Housley = > > *Gesendet:* Mittwoch, 8. Mai 2019 02:18 > *An:* Brockhaus, Hendrik (CT RDA ITS SEA-DE)=20 > > > *Cc:* spasm@ietf.org ; Jim Schaad=20 > >; Fries,=20 > Steffen (CT RDA ITS) > > *Betreff:* Re: [lamps] Follow-up on lightweight CMP profile > > Hendrik: > > The current re-charter is about two weeks away. =A0You would need to=20 > propose text for the charter on this list, and see if there are people = > that will review and implement. > > Russ > > On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > > wrote: > > Hi all > > Referring to the Email thread 'Seeking guidance on proceeding with > question from IETF-104 presentation on lightweight CMP profile' > and to the outcome of the WG meeting, we want to summarize the > current state of the discussion. > > The discussion we had with Jim motivate a split of the current > draft into a CMP Updates and a CMP Profile document. The update of > CMP is needed because we identified at least two point where a > change to CMP is needed: > > - Change the type of encryptedCert from EncryptedValue to > EncryptedKey for ECC and post-quantum algorithm support > > - Extend the RootCAUpdate announcement message to e > request/response message to enable requesting the update from the > client side > > The remaining points from the initial email were seen as profiling > topic and would therefore be handled in the CMP Profile document...= > > @Russ, how do you see the status of the current re-chartering > process? Would you support to add both, or at least the CMP > Updates, activities under the revised charter? > > - Hendrik > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > > > > _______________________________________________ > 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 --------------6D52ED8AA17D9AC797A7DD10 Content-Type: multipart/related; boundary="------------CDB6C7E98F3818FD03DE8D1D" --------------CDB6C7E98F3818FD03DE8D1D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Hendrik, all,

I too support this effort and I have few use-cases that might be relevant.

First of all, this work is something I needed to do for the EAP-CREDS (Credentials Management over EAP) work (we need a simplified profile for the EAP-CREDS to work :D).

Another important use case we have is related to medical devices (we have been working with CMI for a while now): in that environment we need to use reasonably-lived certificates (not the usual 20yrs device cert) with frequent renewals: when trying to select a simple protocol, CMP seemed the right choice over others because of its ease of implementation and flexibility.

Another use-case is within Wireless Broadband Alliance (WBA) - there, we are working to define and deploy a RadSec-only deployment for a WBA-centric roaming infrastructure, and part of that work is to define how to deliver server-side (but, in the future, also client-side via EAP-CREDS :D) certificates.

We are also evaluating the deployment of the same (or very similar) approach for the DOCSIS(r) standard (Cable Networks).

I also want to point out that CMP is already used in 3gpp (the very basic version) in their SIM-based (only for an initial authentication) certificate provisioning system (well, just the very basic of the protocol here).

Last but not least, I do like CMP because it allows me to use it independently from the transport protocol, which is a huge win for me (e.g., when granting access to the network and connectivity is not there yet, I want to be able to provision/manage the credentials even before the device goes online). Something like ACME, for example, it is completely useless for all my use-cases (and super inefficient :D).

I will be happy to provide my input for the work, if needed :D

Just my 2 cents...

Cheers,
Max


On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote:

Hi Panos,

 

missed you in Prague.

 

Steffen had a discussion on the focus of our CMP profile with Jim after the ACE meeting in Prague. May be we did not focus enough on industrial use cases. Our focus in not in the first place on constrained devices, but we believe that CMP would also work perfectly on all those devices capable to run TLS.

Currently CMP is already used in mobile networks and in rail networks.. But we see the need to specify the needed uses cases in more detail to get interoperable implementations.

The big advantage of CMP for industrial use is that we do not have any security requirements to the transport of the messages, since CMP messages are self-contained and support end-to-end security.  A hop-by-hop security or asynchronous transport is not always feasible.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm@ietf.org; Russ Housley <housley@vigilsec.com>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

 

 

Hi Hendrik,

 

Long time since we talked.

 

With such a profile, I have a concern that what happened with SCEP, CMC, CMPv2, EST is likely to happen in constrained environments. Using two or more protocols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation and confuse vendors that want to pick one.

 

I am not sure I have heard a broad need for a CMP profile in ACE. If this is a single vendor need, does IETF even need to standardize this CMP profile?

 

Panos

 

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housley <housley@vigilsec.com>
Cc: Jim Schaad <ietf@augustcellars.com>; steffen.fries@siemens.com
Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on this list we would like to spend further work on updating and profiling CMP focusing on industrial use cases.

To get input, feedback and support from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important in industrial environments, it needs to be tailored to the specific needs. CMP as existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be enhanced to more efficiently support of industrial use cases, crypto agility and specific communication relations on the one hand and profiled to the necessary functionality on the other hand to ease application and to better facilitate interoperable implementation. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile

 

Hendrik:

 

The current re-charter is about two weeks away.  You would need to propose text for the charter on this list, and see if there are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile' and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the current draft into a CMP Updates and a CMP Profile document. The update of CMP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue to EncryptedKey for ECC and post-quantum algorithm support

- Extend the RootCAUpdate announcement message to e request/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as profiling topic and would therefore be handled in the CMP Profile document...

 

@Russ, how do you see the status of the current re-chartering process? Would you support to add both, or at least the CMP Updates, activities under the revised charter?

 

- Hendrik

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

 


_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
--------------CDB6C7E98F3818FD03DE8D1D Content-Type: image/png; name="blpbdbppaoneknpc.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="blpbdbppaoneknpc.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= --------------CDB6C7E98F3818FD03DE8D1D-- --------------6D52ED8AA17D9AC797A7DD10-- From nobody Thu May 9 10:22:44 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069DB12003E for ; Thu, 9 May 2019 10:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uL6OUA3X9wBE for ; Thu, 9 May 2019 10:22:25 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80085.outbound.protection.outlook.com [40.107.8.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5259212016D for ; Thu, 9 May 2019 10:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YlR2a0pm+LaRISvy6QAbZPDal3l9GPBJdhjT1x3uomE=; b=0hhnmHoipXGK524Z0fSC8v1HngKI7zr5BmwwkDS4I4gwtd10Naj8NOK5ZFa6vqvnlnJGQlyaBwVrJXMhi+PyckRGGZ69GeGJiWDYGGGkkz0wN6NFqBZ/qy4Iq1OL2vZmkcRihTLVTvE5w6lOaW/2cDSCyf6VjMi/EO9mPe1z7v8= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2817.EURPRD10.PROD.OUTLOOK.COM (20.178.117.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Thu, 9 May 2019 17:22:22 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1856.012; Thu, 9 May 2019 17:22:22 +0000 From: "Brockhaus, Hendrik" To: "spasm@ietf.org" , "Peylo, Martin (Nokia - FI/Espoo)" , "Dr. Pala" CC: Jim Schaad , "steffen.fries@siemens.com" , Russ Housley Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAACRFEAAODOVoA== Date: Thu, 9 May 2019 17:22:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [77.9.0.253] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51a538b6-e903-41c1-1dea-08d6d4a2e5bd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2817; x-ms-traffictypediagnostic: AM0PR10MB2817: x-ms-exchange-purlcount: 2 x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(366004)(346002)(39860400002)(189003)(53754006)(199004)(42274003)(52314003)(54906003)(6436002)(2420400007)(8676002)(8936002)(316002)(102836004)(66066001)(256004)(14444005)(186003)(110136005)(81156014)(81166006)(86362001)(53546011)(15650500001)(236005)(478600001)(2501003)(54896002)(53936002)(6306002)(5660300002)(9686003)(6506007)(14454004)(19627235002)(6116002)(3846002)(64756008)(66446008)(66476007)(66556008)(68736007)(446003)(7110500001)(2906002)(11346002)(76116006)(66946007)(55016002)(73956011)(476003)(966005)(76176011)(486006)(4326008)(99286004)(7696005)(26005)(7736002)(71190400001)(52536014)(790700001)(606006)(33656002)(25786009)(71200400001)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2817; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: +4+q3KUr4lGQYzXj/HahXende0mkQInSXAU4FWqNEt8GRbz6sx+N7XbssNmUVK6lOoNQPoUp2X4aPWo+WIGg4zp6TBeVpsoD/cUbDHTHwZ0eiYM0+AiRbb8xAHSyRGcgRJSeEJp5cfELaJRN0EZTMU8gtBsBYYHg/huW0Z9cVABnEAiBLz81jLPj9yPX4AQXwR7yDxkbxMApymLSgJJI8ArdTRBGFidmIRJtmUFDmYbJMj/VO5SZYb4sdopdRyMIOqKZafeFpO/ud4nKBkvLMKUKWZwKV71Y3kQcYtBM9BTMlm8IFduaRPGhc8tB0wTPTRya/QHNiDGsEsW1FaVhiC090ufxf7UtVidk/mTXtturO7uSELB5dcnS7BUtMx4u+kGuVJuNxnpqtL9leLNh+GfcLSMleM49zSB4UAC49DM= Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24029AF6D82DDE3E81347F04FE330AM0PR10MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51a538b6-e903-41c1-1dea-08d6d4a2e5bd X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 17:22:22.2461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2817 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 17:22:41 -0000 --_000_AM0PR10MB24029AF6D82DDE3E81347F04FE330AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Martin, hi Max, thank you for your support. Martin mentioned his Mbed(tm) based CMP implementation. This was a great st= arting point for us to extend the implementation to support further use cas= es specified in the CMP profile. It works perfectly fine on the NXP board. = We plan to provide the code open source as soon as we have time to do so :-= ) Thanks to Max for describing his use cases. I am happy to get his input to = our I-D and also like to offer my support on his EAP-CREDS draft, too. Hendrik Von: Peylo, Martin (Nokia - FI/Espoo) Gesendet: Mittwoch, 8. Mai 2019 16:54 An: Panos Kampanakis (pkampana) ; spasm@ietf.org; Russ = Housley ; Brockhaus, Hendrik (CT RDA ITS SEA-DE) Cc: Jim Schaad ; Fries, Steffen (CT RDA ITS) Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi, I see good value of clear CMP profiles for different use cases. The actual problem why CMP isn't as widely used as it could be is that it a= ims to cater for every possible and impossible use case. RFC 4210, Appendix= D certainly has room for improvement; To be conformant, implementers need = to add features very few users would actually want to use, e.g. the second = CertReqMsg in an IR. The plethora of options certainly is the main issue fo= r implementing with wide interworking - there are e.g. multiple meaningful = ways to implement RA-CA communications. So, clear CMP profiles will be a va= luable tool for implementers to provide interoperable clients and servers f= or defined use cases. Panos, I haven't followed ACE lately, but I could imagine that also users o= f the work currently done in ACE could benefit from this. CMP caters very w= ell for the needs of RA-CA communications, and there are many scenarios whe= re PKIs for constrained devices benefit from utilizing RAs. So, also a clea= r profile for RA-CA communication would certainly be a benefit the constrai= ned-device world, even if it is not directly visible on the constrained dev= ices themselves. But anyway, it appears quite possible to shrink a CMP implementation for a = constrained device. As a PoC, I have implemented a rudimentary CMP client [= 1] for Mbed(tm) in 2017. As minimal profile, I basically did IR with MSG_SI= G_ALG and implicit confirm - that worked well on a FRDM-K64F. A careful update for RFC 4210 should also allow to refresh the list of mand= atory algorithms, not least putting SHA-1 and 3-DES to rest. I'm looking forward to discussing details of profiles and other enhancement= s to the protocol specification. Cheers, Martin [1] https://github.com/nokia/CMPclient-embedded-lib From: Spasm > On Beha= lf Of Panos Kampanakis (pkampana) Sent: Wednesday, May 8, 2019 5:00 PM To: spasm@ietf.org; Russ Housley >; Brockhaus, Hendrik > Cc: Jim Schaad >; ste= ffen.fries@siemens.com Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens..com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_AM0PR10MB24029AF6D82DDE3E81347F04FE330AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Martin= , hi Max,

&nbs= p;

thank you for your support.

 

Martin mentioned his Mbed™= ; based CM= P implementation. This was a great starting point for us to extend the impl= ementation to support further use cases specified in the CMP profile. It works perfectly fine on the NXP board. We plan to p= rovide the code open source as soon as we have time to do so :-)=

 

Thanks to Max for describing his use cases. I am happy to get his inp= ut to our I-D and also like to offer my support on his EAP-CREDS draft, too= .

 

Hendrik

 

Von: Peylo, Martin (Nokia - FI/Espoo) <mar= tin.peylo@nokia.com>
Gesendet: Mittwoch, 8. Mai 2019 16:54
An: Panos Kampanakis (pkampana) <pkampana@cisco.com>; spasm@ie= tf.org; Russ Housley <housley@vigilsec.com>; Brockhaus, Hendrik (CT R= DA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RD= A ITS) <steffen.fries@siemens.com>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

Hi,

 

I see good value of clear CMP profiles for different use cases.

 

The actual problem why CMP isn’t as widely used as it could be = is that it aims to cater for every possible and impossible use case. RFC 42= 10, Appendix D certainly has room for improvement; To be conformant, implementers need to add features very few users would a= ctually want to use, e.g. the second CertReqMsg in an IR. The plethora of o= ptions certainly is the main issue for implementing with wide interworking = – there are e.g. multiple meaningful ways to implement RA-CA communications. So, clear CMP profiles will be a v= aluable tool for implementers to provide interoperable clients and servers = for defined use cases.

 

Panos, I haven’t followed ACE lately, but I could imagine that = also users of the work currently done in ACE could benefit from this. CMP c= aters very well for the needs of RA-CA communications, and there are many scenarios where PKIs for constrained devices benefit fr= om utilizing RAs. So, also a clear profile for RA-CA communication would ce= rtainly be a benefit the constrained-device world, even if it is not direct= ly visible on the constrained devices themselves.

 

But anyway, it appears quite possible to shrink a CMP implementation = for a constrained device. As a PoC, I have implemented a rudimentary CMP cl= ient [1] for Mbed™ in 2017. As minimal profile, I basically did IR with MSG_SIG_ALG and implicit confirm – = that worked well on a FRDM-K64F.

 

A careful update for RFC 4210 should also allow to refresh the list o= f mandatory algorithms, not least putting SHA-1 and 3-DES to rest.

 

I’m looking forward to discussing details of profiles and other= enhancements to the protocol specification.

 

Cheers,

Martin

 

 

[1] https://github.com/nokia/CMPclient-embedded-lib

 

From: Spasm <spasm-bounc= es@ietf.org> On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, May 8, 2019 5:00 PM
To: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>= ; Brockhaus, Hendrik <h= endrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@au= gustcellars.com>; steffen.fries@siemens.com<= br> Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

&n= bsp;

Hi Hend= rik,

&n= bsp;

Long ti= me since we talked.

&n= bsp;

With su= ch a profile, I have a concern that what happened with SCEP, CMC, CMPv2, ES= T is likely to happen in constrained environments. Using two or more protoc= ols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation= and confuse vendors that want to pick one.

&n= bsp;

I am no= t sure I have heard a broad need for a CMP profile in ACE. If this is a sin= gle vendor need, does IETF even need to standardize this CMP profile?<= /o:p>

&n= bsp;

Panos

&n= bsp;

&n= bsp;

 

Hi Russ, all,

 

as discussed at IETF104 and on = this list we would like to spend further work on updating and profiling CMP= focusing on industrial use cases.

To get input, feedback and supp= ort from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important = in industrial environments, it needs to be tailored to the specific needs. = CMP as existing protocol offers a vast range of options. As it is already being applied in industrial environments it need= s to be enhanced to more efficiently support of industrial use cases, crypt= o agility and specific communication relations on the one hand and profiled= to the necessary functionality on the other hand to ease application and to better facilitate interoperab= le implementation. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.c= om> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ..

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

_______________________________________________ Spasm mailing list
Spasm@ietf.org
 

--_000_AM0PR10MB24029AF6D82DDE3E81347F04FE330AM0PR10MB2402EURP_-- From nobody Thu May 9 11:55:51 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283BF12013D for ; Thu, 9 May 2019 11:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hICInEGQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Mg+YRXaM 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 9d4BqRpxaePe for ; Thu, 9 May 2019 11:55:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA1B120110 for ; Thu, 9 May 2019 11:55:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24082; q=dns/txt; s=iport; t=1557428147; x=1558637747; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ofWOyyqQ2pcl2DuyL8/N0Sk85ZcjzBPsZDPP3RGQ1Dk=; b=hICInEGQkRVvvb9NTVMidpD9TsQNC8/q0EPk8QlE0o8k+o1X29rfcX22 aVwNG38lErWOtTdwgkgWbEuwwOfP1Oon/sIzdUbNVlIolidEt/k4CT050 D+ILs02gpXZ6TZX8r0IKuLuElFVnRoHiZoshL9REXCM0CUqTD1u2AfBsH s=; IronPort-PHdr: =?us-ascii?q?9a23=3ATL3D5B8L/lNbRv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaGAEjjJfjjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAAD5dtRc/5pdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgQ4vJCwDaVUgBAsoh1gDjn2CV5clgUK?= =?us-ascii?q?BEANUCQEBAQwBARgBCQsCAQGBBV2CXgKCCCM3Bg4BAwEBBAEBAgEEbRwMhUo?= =?us-ascii?q?BAQEEAQEQGxMBASwEBwEPAgEIEQQBASEDBAcnCxQJCAEBBAENBQgagnsEAoE?= =?us-ascii?q?dTQMdAQ6iGgKBNYhfgiCCeQEBBYUEAxWCDwMGgTIBiguBQxeBQD+BEUaCHi4?= =?us-ascii?q?+gmEBAQIYgQsJARIBISsJgwaCBCKKfCERJIZWiAqNFwkCggmGHYxSghCTSYh?= =?us-ascii?q?rgzqBIZNWAgQCBAUCDgEBBYFlIg1ZcXAVO4JsE4FYJAwXFIM4hRSFP3IBAQE?= =?us-ascii?q?BgSWME4FUbwEB?= X-IronPort-AV: E=Sophos;i="5.60,450,1549929600"; d="scan'208,217";a="560640736" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 May 2019 18:55:46 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x49ItjTR012218 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2019 18:55:45 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 13:55:45 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 14:55:44 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 May 2019 14:55:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=stReu9JHc91HRt/Crwy/E5/4MGO2dvAW6hKTfny//R0=; b=Mg+YRXaMCugaTIxXvIpLZcTPFrkPQKMr6Foouvrvv6+HISuyfzx543YLauTs4SM3FnMeFR54fB1W49feF7Ccm1F4E6fcEdhl9ZB/niZGwB7eoKE/DfuL3uY/k4ZCBZHVTZRnxauNdz175/C9juCClqza4X7xGwZ9sCq0/zmpM5k= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (10.175.53.141) by MWHPR11MB1310.namprd11.prod.outlook.com (10.169.237.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.20; Thu, 9 May 2019 18:55:42 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::4964:5495:9121:8f12]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::4964:5495:9121:8f12%7]) with mapi id 15.20.1878.022; Thu, 9 May 2019 18:55:42 +0000 From: "Panos Kampanakis (pkampana)" To: "Brockhaus, Hendrik" , "spasm@ietf.org" CC: Jim Schaad , Russ Housley , "steffen.fries@siemens.com" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAAIqrYAAGMXOoA== Date: Thu, 9 May 2019 18:55:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:2090:1009:98b8:ca19:316a:b117] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2efe0e8d-200a-465d-ee02-08d6d4afefbd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MWHPR11MB1310; x-ms-traffictypediagnostic: MWHPR11MB1310: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(366004)(39860400002)(136003)(189003)(199004)(53754006)(4326008)(6306002)(54896002)(71200400001)(81166006)(236005)(606006)(6506007)(102836004)(53546011)(9686003)(2420400007)(186003)(14454004)(8676002)(71190400001)(15650500001)(229853002)(7110500001)(25786009)(81156014)(7736002)(55016002)(52536014)(6436002)(53936002)(66476007)(46003)(68736007)(2906002)(66446008)(66556008)(64756008)(316002)(66946007)(73956011)(2501003)(256004)(14444005)(76116006)(33656002)(9326002)(5660300002)(54906003)(110136005)(8936002)(74316002)(6116002)(7696005)(790700001)(486006)(6246003)(11346002)(446003)(476003)(76176011)(478600001)(99286004)(86362001)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1310; H:MWHPR11MB1838.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wJbfGy7aLpCAQ5DT5VfozxIWZwNR7wsjLhgMdHJf7/5Fd+TjPaXjxzCOl2k0crWDkJDXwzxiqd4IFAm6vWjzr7P7skWfq3E/0oO8lI0AM953AbyK0sfX98imilPQhaHkQ/VGvLyDyg62GA/apQ29gUd1uZGzBX00XTlCbpS2wpJznX1xXBgFv3HaSGIfTJslnShZMsjHN7/M8FF+J4TZTPzO/ywTLG/k5vDvwMFl7VmW7VWsiZN0E02/e/VdzuTLDMdkJ0qkkiYlz1svfBSom+V0Meorgd9P3dCk3B2yG0pLR/WsSx+oZls/Au+gXx2OxIQNHBEJPYlMjplZRghQy1e39NaN+icR7bJnC9WxzPsTq8HXcC7ClZqwUswoiWI6NiOLiONqOnAEF3ZfnAy6SAxBGOz60zPL93Nsz0QtobU= Content-Type: multipart/alternative; boundary="_000_MWHPR11MB18382E8686BF5B7396670A94C9330MWHPR11MB1838namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2efe0e8d-200a-465d-ee02-08d6d4afefbd X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 18:55:42.4779 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1310 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 18:55:50 -0000 --_000_MWHPR11MB18382E8686BF5B7396670A94C9330MWHPR11MB1838namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hendrik, Understood. I don't question that CMP has it uses; I wanted to avoid a new = profile causing confusion in areas where there were other options. Another question. Why is this a LAMPS item? Creating a CMP profile that ap= plies to a specific vertical resembles a recent case where a draft was brou= ght to the TLS WG for V2V certificates in TLS. The TLS WG did not pick up t= he draft because of lack of interest and the narrow usecase. Why should thi= s item be part of the LAMPS charter and not ISO ICS or IEC that seem more n= atural homes? Thanks, Panos From: Spasm On Behalf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 11:02 AM To: Panos Kampanakis (pkampana) ; spasm@ietf.org Cc: Jim Schaad ; Russ Housley ; steffen.fries@siemens.com Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Panos, missed you in Prague. Steffen had a discussion on the focus of our CMP profile with Jim after the= ACE meeting in Prague. May be we did not focus enough on industrial use ca= ses. Our focus in not in the first place on constrained devices, but we bel= ieve that CMP would also work perfectly on all those devices capable to run= TLS. Currently CMP is already used in mobile networks and in rail networks.. But= we see the need to specify the needed uses cases in more detail to get int= eroperable implementations. The big advantage of CMP for industrial use is that we do not have any secu= rity requirements to the transport of the messages, since CMP messages are = self-contained and support end-to-end security. A hop-by-hop security or a= synchronous transport is not always feasible. Hendrik Von: Panos Kampanakis (pkampana) > Gesendet: Mittwoch, 8. Mai 2019 16:00 An: spasm@ietf.org; Russ Housley >; Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: Jim Schaad >; Fri= es, Steffen (CT RDA ITS) > Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens.com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_MWHPR11MB18382E8686BF5B7396670A94C9330MWHPR11MB1838namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Hendrik,

Understood. I don̵= 7;t question that CMP has it uses; I wanted to avoid a new profile causing = confusion in areas where there were other options.

Another question. &nbs= p;Why is this a LAMPS item? Creating a CMP profile that applies to a specif= ic vertical resembles a recent case where a draft was brought to the TLS WG= for V2V certificates in TLS. The TLS WG did not pick up the draft because of lack of interest and the narrow useca= se. Why should this item be part of the LAMPS charter and not ISO ICS or IE= C that seem more natural homes?

 

Thanks,
Panos

 

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 11:02 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; spasm@ie= tf.org
Cc: Jim Schaad <ietf@augustcellars.com>; Russ Housley <hous= ley@vigilsec.com>; steffen.fries@siemens.com
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /p>

 

Hi Panos,

 

missed you in Prague.

 

Steffen had a discussion on the focus of our CMP pro= file with Jim after the ACE meeting in Prague. May be we did not focus enou= gh on industrial use cases. Our focus in not in the first place on constrai= ned devices, but we believe that CMP would also work perfectly on all those devices capable to run TLS.

Currently CMP is already used in mobile networks and= in rail networks.. But we see the need to specify the needed uses cases in= more detail to get interoperable implementations.

The big advantage of CMP for industrial use is that = we do not have any security requirements to the transport of the messages, = since CMP messages are self-contained and support end-to-end security. &nbs= p;A hop-by-hop security or asynchronous transport is not always feasible.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm= @ietf.org; Russ Housley <housley@vigilsec.com<= /a>>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <= ietf@augustcellars.com>; = Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

 

Hi Hendrik,=

 

Long time since we tal= ked.

 

With such a profile, I= have a concern that what happened with SCEP, CMC, CMPv2, EST is likely to = happen in constrained environments. Using two or more protocols (EST-coaps,= a CMP profile over different transports, and others) that do similar things would lead to fragmentation and confuse= vendors that want to pick one.

 

I am not sure I have h= eard a broad need for a CMP profile in ACE. If this is a single vendor need= , does IETF even need to standardize this CMP profile?

 

Panos

 

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; steffen.fries@siemens.com<= br> Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on this list we would li= ke to spend further work on updating and profiling CMP focusing on industri= al use cases.

To get input, feedback and support from LAMPS we pro= pose the following charter text.

 

As certificate management gets increasingly important in industrial e= nvironments, it needs to be tailored to the specific needs. CMP as existing= protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be enhance= d to more efficiently support of industrial use cases, crypto agility and s= pecific communication relations on the one hand and profiled to the necessa= ry functionality on the other hand to ease application and to better facilitate interoperable implementation.=  

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siem= ens.com>
Cc: spasm= @ietf.org; Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about tw= o weeks away.  You would need to propose text for the charter on this = list, and see if there are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockh= aus, Hendrik <hendrik.brockhaus@siemens.com&= gt; wrote:

 

Hi= all

&n= bsp;

Re= ferring to the Email thread 'Seeking guidance on proceeding with question f= rom IETF-104 presentation on lightweight CMP profile' and to the outcome of= the WG meeting, we want to summarize the current state of the discussion.

Th= e discussion we had with Jim motivate a split of the current draft into a C= MP Updates and a CMP Profile document. The update of CMP is needed because = we identified at least two point where a change to CMP is needed:

- = Change the type of encryptedCert from EncryptedValue to EncryptedKey for EC= C and post-quantum algorithm support

- = Extend the RootCAUpdate announcement message to e request/response message = to enable requesting the update from the client side=

Th= e remaining points from the initial email were seen as profiling topic and = would therefore be handled in the CMP Profile document...=

&n= bsp;

@R= uss, how do you see the status of the current re-chartering process? Would = you support to add both, or at least the CMP Updates, activities under the = revised charter?

&n= bsp;

- = Hendrik

______________________________________= _________
Spasm mailing list
Spasm@= ietf.org
https://www.ietf.org/mailman/listinfo/spasm

 

--_000_MWHPR11MB18382E8686BF5B7396670A94C9330MWHPR11MB1838namp_-- From nobody Thu May 9 11:55:59 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB77212014A for ; Thu, 9 May 2019 11:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.501 X-Spam-Level: X-Spam-Status: No, score=-12.501 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=A93IOn0Q; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XoJ1XOg0 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 g4VhzQ-8zXIa for ; Thu, 9 May 2019 11:55:46 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 958731200E9 for ; Thu, 9 May 2019 11:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33296; q=dns/txt; s=iport; t=1557428146; x=1558637746; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ZIDOz20ORbPcgFefBOq2SKybzQxxoWcG6qG9eu4QRTc=; b=A93IOn0QZNzpJNDhFMzOBHJ7zGMdqffGQrYnkgAlhzge0TAgAkBDUFe/ KNCX8tlIuQRjuSat0ITa0kBCt8JnhLDkFe9T1g6GkcTR27ORMm46jxklH j/mYumHV+0QRLS2JlI0FvHEeW/sIrNewb/nlurHjqvSj70qIh6I4L6Oaf w=; X-Files: image001.png : 3146 IronPort-PHdr: =?us-ascii?q?9a23=3AxUDDFxVrU3j5ecoeT0lXiK5ZbNXV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankiH81HTFZj9lmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BTAAD5dtRc/4cNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZYEPLyQsA2lVIAQLKIdYA459gleXJYFCgRADVAIHAQE?= =?us-ascii?q?BCQECAQEYAQkLAgEBgQVdgl4CgggjOBMBAwEBBAEBAgEEbRwMhUoBAQEDAQE?= =?us-ascii?q?BAw0TCAESAQEsBAgECwIBCBEEAQEGAQEBGAMEBwIFEAEOAQsUCQgBAQQBEQE?= =?us-ascii?q?GAgYQBIJ7BAKBagMODwEOohoCgTWIX4IgH4JaAQEFhQQDFYIIBwMGgTKKDIF?= =?us-ascii?q?DF4FAP4ERRoFOUC4+gmEBAQIYgQsJARIBCRgVFgmDBoIEIosdESSGVogKhFe?= =?us-ascii?q?COYUiZQkCggmFHQF/jFKCEJNJiGuCI4EXgSGTVgIEAgQFAg4BAQWBZiENWXF?= =?us-ascii?q?wFTuCbBOBWCQMFxSDOIUUhT9yAQEBAYEljBOBVG8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,450,1549929600"; d="png'150?scan'150,208,217,150";a="560640731" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 May 2019 18:55:45 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x49ItinI024265 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 May 2019 18:55:44 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 13:55:43 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 9 May 2019 13:55:43 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 9 May 2019 14:55:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zM7uJjhaT6Fs/r1YCfkWUaTmV553UCYZW7sSuBUWry4=; b=XoJ1XOg0Fn9MpCSdmipB+q4EadTHPTb7+XU1TRJzLsetGJMUSz8wZ19s3ADCLjiCYGCV7GMPbUdmh0NNEqZUUDVgjwi/6rgizkBCIZWYiJus0MU+QrXPRLmt8bkxg5/tUGoYyi+227cawiCZAYOhC9+osoJM6ccwT4Ea0AAIkDI= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (10.175.53.141) by MWHPR11MB1310.namprd11.prod.outlook.com (10.169.237.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.20; Thu, 9 May 2019 18:55:41 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::4964:5495:9121:8f12]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::4964:5495:9121:8f12%7]) with mapi id 15.20.1878.022; Thu, 9 May 2019 18:55:41 +0000 From: "Panos Kampanakis (pkampana)" To: "Dr. Pala" , "spasm@ietf.org" Thread-Topic: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAAIqrYAAEZjLAAAHHK5g Date: Thu, 9 May 2019 18:55:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:2090:1009:98b8:ca19:316a:b117] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3724aae6-45a6-443c-ff82-08d6d4afef56 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:MWHPR11MB1310; x-ms-traffictypediagnostic: MWHPR11MB1310: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 003245E729 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(366004)(39860400002)(136003)(189003)(199004)(53754006)(6306002)(54896002)(71200400001)(81166006)(236005)(606006)(6506007)(102836004)(53546011)(9686003)(2420400007)(186003)(14454004)(54556002)(8676002)(71190400001)(15650500001)(229853002)(99936001)(7110500001)(25786009)(81156014)(7736002)(55016002)(52536014)(6436002)(53936002)(66476007)(46003)(68736007)(2906002)(66446008)(733005)(66616009)(66556008)(64756008)(316002)(66946007)(73956011)(2501003)(256004)(14444005)(76116006)(33656002)(9326002)(5660300002)(110136005)(8936002)(74316002)(6116002)(7696005)(790700001)(486006)(6246003)(11346002)(446003)(476003)(76176011)(478600001)(99286004)(86362001)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1310; H:MWHPR11MB1838.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: enjYP4DjhFS5iva986TPu8ZAf4ZKOUEzw7/aespCjQkfBvnOFJ3NF56YL6HKhmxaU3UMfaVEJ6MJ7JWgqg9jnVLTiUe6HRuhZJjmZi1hBffC1qR/ddAkHVa+RmT+OZTD/NQmCv4XnSWv8HmOv3SsgjC/3aTP0782aBg57Hwl/ffVXe0NbdRrYh2eMvMYglTvY6FQh5TDg/BiXn1XK467QBKIvY4JRon4Qr79f5/0ofWjzNUOuSD9zkhFZdOspGD2L0OanmlCio0nhnLHbQ8+sRqYK5PiVAnlDyBfbsab6XbhvOFyu5BctDTEu05kze0Auft50anwdKI3y9lBMnzCjaisoU9a3YyUB6R3VSkegFJw/+RJNN5/5XCj7HbUvW8WRssXyaZfYqYy3B+fLxFG7wT7JAweyTF+ZNJ2T83xU8I= Content-Type: multipart/related; boundary="_004_MWHPR11MB1838F03FB8F96395A298DEDAC9330MWHPR11MB1838namp_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3724aae6-45a6-443c-ff82-08d6d4afef56 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2019 18:55:41.7673 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1310 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 18:55:54 -0000 --_004_MWHPR11MB1838F03FB8F96395A298DEDAC9330MWHPR11MB1838namp_ Content-Type: multipart/alternative; boundary="_000_MWHPR11MB1838F03FB8F96395A298DEDAC9330MWHPR11MB1838namp_" --_000_MWHPR11MB1838F03FB8F96395A298DEDAC9330MWHPR11MB1838namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Max, > First of all, this work is something I needed to do for the EAP-CREDS (Cr= edentials Management over EAP) work (we need a simplified profile for the E= AP-CREDS to work :D). Is this the same profile proposed in Hendrik's draft or a different one? I don't question that CMP has it uses, but are the rest of the usecases you= listed out interested in using Hendrik's profile or are they just interest= ed in CMP native? Rgs, Panos From: Spasm > On Beha= lf Of Dr. Pala Sent: Wednesday, May 08, 2019 7:12 PM To: spasm@ietf.org Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, all, I too support this effort and I have few use-cases that might be relevant. First of all, this work is something I needed to do for the EAP-CREDS (Cred= entials Management over EAP) work (we need a simplified profile for the EAP= -CREDS to work :D). Another important use case we have is related to medical devices (we have b= een working with CMI for a while now): in that environment we need to use r= easonably-lived certificates (not the usual 20yrs device cert) with frequen= t renewals: when trying to select a simple protocol, CMP seemed the right c= hoice over others because of its ease of implementation and flexibility. Another use-case is within Wireless Broadband Alliance (WBA) - there, we ar= e working to define and deploy a RadSec-only deployment for a WBA-centric r= oaming infrastructure, and part of that work is to define how to deliver se= rver-side (but, in the future, also client-side via EAP-CREDS :D) certifica= tes. We are also evaluating the deployment of the same (or very similar) approac= h for the DOCSIS(r) standard (Cable Networks). I also want to point out that CMP is already used in 3gpp (the very basic v= ersion) in their SIM-based (only for an initial authentication) certificate= provisioning system (well, just the very basic of the protocol here). Last but not least, I do like CMP because it allows me to use it independen= tly from the transport protocol, which is a huge win for me (e.g., when gra= nting access to the network and connectivity is not there yet, I want to be= able to provision/manage the credentials even before the device goes onlin= e). Something like ACME, for example, it is completely useless for all my u= se-cases (and super inefficient :D). I will be happy to provide my input for the work, if needed :D Just my 2 cents... Cheers, Max On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote: Hi Panos, missed you in Prague. Steffen had a discussion on the focus of our CMP profile with Jim after the= ACE meeting in Prague. May be we did not focus enough on industrial use ca= ses. Our focus in not in the first place on constrained devices, but we bel= ieve that CMP would also work perfectly on all those devices capable to run= TLS. Currently CMP is already used in mobile networks and in rail networks.. But= we see the need to specify the needed uses cases in more detail to get int= eroperable implementations. The big advantage of CMP for industrial use is that we do not have any secu= rity requirements to the transport of the messages, since CMP messages are = self-contained and support end-to-end security. A hop-by-hop security or a= synchronous transport is not always feasible. Hendrik Von: Panos Kampanakis (pkampana) Gesendet: Mittwoch, 8. Mai 2019 16:00 An: spasm@ietf.org; Russ Housley ; Brockhaus, Hendrik (CT RDA ITS SEA-DE) Cc: Jim Schaad ; Fri= es, Steffen (CT RDA ITS) Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens.com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director [OpenCA Logo] --_000_MWHPR11MB1838F03FB8F96395A298DEDAC9330MWHPR11MB1838namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Max,

 

> First of all, thi= s work is something I needed to do for the EAP-CREDS (Credentials Managemen= t over EAP) work (we need a simplified profile for the EAP-CREDS to work :D= ).

 

Is this the same profi= le proposed in Hendrik’s draft or a different one?

 

I don’t question= that CMP has it uses, but are the rest of the usecases you listed out inte= rested in using Hendrik’s profile or are they just interested in CMP = native?


Rgs,

Panos

 

From:= Spasm <spasm-bounces@ietf.org> On Behalf Of Dr. Pala
Sent: Wednesday, May 08, 2019 7:12 PM
To: spasm@ietf.org
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Hendrik, all,

I too support this effort and I have few use-cases that might be relevan= t.

First of all, this work is something I needed to do for the EAP-CREDS (C= redentials Management over EAP) work (we need a simplified profile for the = EAP-CREDS to work :D).

Another important use case we have is related to medical devices (we hav= e been working with CMI for a while now): in that environment we need to us= e reasonably-lived certificates (not the usual 20yrs device cert) with freq= uent renewals: when trying to select a simple protocol, CMP seemed the right choice over others because of its = ease of implementation and flexibility.

Another use-case is within Wireless Broadband Alliance (WBA) - there, we= are working to define and deploy a RadSec-only deployment for a WBA-centri= c roaming infrastructure, and part of that work is to define how to deliver= server-side (but, in the future, also client-side via EAP-CREDS :D) certificates.

We are also evaluating the deployment of the same (or very similar) appr= oach for the DOCSIS(r) standard (Cable Networks).

I also want to point out that CMP is already used in 3gpp (the very basi= c version) in their SIM-based (only for an initial authentication) certific= ate provisioning system (well, just the very basic of the protocol here).

Last but not least, I do like CMP because it allows me to use it indepen= dently from the transport protocol, which is a huge win for me (e.g., when = granting access to the network and connectivity is not there yet, I want to= be able to provision/manage the credentials even before the device goes online). Something like ACME, for = example, it is completely useless for all my use-cases (and super inefficie= nt :D).

I will be happy to provide my input for the work, if needed :D

Just my 2 cents...

Cheers,
Max

 

On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote:

Hi Panos,

 

missed you in Prague.

 

Steffen had a discussion on the focus of our CMP pro= file with Jim after the ACE meeting in Prague. May be we did not focus enou= gh on industrial use cases. Our focus in not in the first place on constrai= ned devices, but we believe that CMP would also work perfectly on all those devices capable to run TLS.

Currently CMP is already used in mobile networks and= in rail networks.. But we see the need to specify the needed uses cases in= more detail to get interoperable implementations.

The big advantage of CMP for industrial use is that = we do not have any security requirements to the transport of the messages, = since CMP messages are self-contained and support end-to-end security. &nbs= p;A hop-by-hop security or asynchronous transport is not always feasible.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@au= gustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com&= gt;
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

 

Hi Hendrik,

 

Long time since we tal= ked.

 

With such a profile, I= have a concern that what happened with SCEP, CMC, CMPv2, EST is likely to = happen in constrained environments. Using two or more protocols (EST-coaps,= a CMP profile over different transports, and others) that do similar things would lead to fragmentation and confuse= vendors that want to pick one.

 

I am not sure I have h= eard a broad need for a CMP profile in ACE. If this is a single vendor need= , does IETF even need to standardize this CMP profile?

 

Panos

 

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; steffen.fries@siemens.com<= br> Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on this list we would li= ke to spend further work on updating and profiling CMP focusing on industri= al use cases.

To get input, feedback and support from LAMPS we pro= pose the following charter text.

 

As certificate management gets increasingly important in industrial e= nvironments, it needs to be tailored to the specific needs. CMP as existing= protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be enhance= d to more efficiently support of industrial use cases, crypto agility and s= pecific communication relations on the one hand and profiled to the necessa= ry functionality on the other hand to ease application and to better facilitate interoperable implementation.=  

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.c= om> wrote:

 

Hi= all

&n= bsp;

Re= ferring to the Email thread 'Seeking guidance on proceeding with question f= rom IETF-104 presentation on lightweight CMP profile' and to the outcome of= the WG meeting, we want to summarize the current state of the discussion.

Th= e discussion we had with Jim motivate a split of the current draft into a C= MP Updates and a CMP Profile document. The update of CMP is needed because = we identified at least two point where a change to CMP is needed:

- = Change the type of encryptedCert from EncryptedValue to EncryptedKey for EC= C and post-quantum algorithm support

- = Extend the RootCAUpdate announcement message to e request/response message = to enable requesting the update from the client side

Th= e remaining points from the initial email were seen as profiling topic and = would therefore be handled in the CMP Profile document...

&n= bsp;

@R= uss, how do you see the status of the current re-chartering process? Would = you support to add both, or at least the CMP Updates, activities under the = revised charter?

&n= bsp;

- = Hendrik

_______________________________________________ Spasm mailing list
Spasm@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/spasm

 



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

--

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

3D"OpenCA

--_000_MWHPR11MB1838F03FB8F96395A298DEDAC9330MWHPR11MB1838namp_-- --_004_MWHPR11MB1838F03FB8F96395A298DEDAC9330MWHPR11MB1838namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3146; creation-date="Thu, 09 May 2019 18:55:40 GMT"; modification-date="Thu, 09 May 2019 18:55:40 GMT" Content-ID: Content-Transfer-Encoding: base64 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= --_004_MWHPR11MB1838F03FB8F96395A298DEDAC9330MWHPR11MB1838namp_-- From nobody Thu May 9 13:59:12 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47168120026; Thu, 9 May 2019 13:59:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <155743555020.24608.12363964410491387388@ietfa.amsl.com> Date: Thu, 09 May 2019 13:59:10 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-06.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 20:59:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource Record Authors : Phillip Hallam-Baker Rob Stradling Jacob Hoffman-Andrews Filename : draft-ietf-lamps-rfc6844bis-06.txt Pages : 18 Date : 2019-05-09 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. This document obsoletes RFC 6844. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc6844bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc6844bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 9 23:48:18 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B80DD12018F for ; Thu, 9 May 2019 23:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJqmy9TXZdtQ for ; Thu, 9 May 2019 23:48:08 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10074.outbound.protection.outlook.com [40.107.1.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6A431201D7 for ; Thu, 9 May 2019 23:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4AfpwnBjt+zTgxyP0nLWJ40Lub95dtPHdQYG1abIboE=; b=OIZw6wJhdqIeGBhgQ6vTbgushRrYUQw04qRHFwRa5glW2Ke8M9XfeWf6+mqScoJDAuK66agJmKvw+kdtV0xhFqAJ/NmJtOfMWW2UXTxN0lF2Wz1Ib2aiJ98pYYfhcuLjPwka0pe9kxwQuMxdYIBkynKvrbczVcIoxuRIcxpozsI= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB1891.EURPRD10.PROD.OUTLOOK.COM (52.134.83.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1856.12; Fri, 10 May 2019 06:47:09 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1856.016; Fri, 10 May 2019 06:47:09 +0000 From: "Brockhaus, Hendrik" To: "Panos Kampanakis (pkampana)" , "spasm@ietf.org" CC: Jim Schaad , Russ Housley , "steffen.fries@siemens.com" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAAIqrYAAGMXOoAA62/yg Date: Fri, 10 May 2019 06:47:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 090f10bf-437f-4109-8718-08d6d5135332 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB1891; x-ms-traffictypediagnostic: AM0PR10MB1891: x-ms-exchange-purlcount: 1 x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0033AAD26D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(136003)(346002)(376002)(366004)(53754006)(189003)(199004)(7696005)(606006)(99286004)(66556008)(66946007)(7110500001)(76116006)(6506007)(64756008)(66476007)(73956011)(102836004)(66446008)(486006)(76176011)(4326008)(33656002)(74316002)(446003)(11346002)(86362001)(476003)(15650500001)(2420400007)(186003)(53936002)(68736007)(3846002)(107886003)(26005)(2906002)(54896002)(9686003)(478600001)(81156014)(6306002)(6436002)(81166006)(8936002)(8676002)(55016002)(2501003)(53546011)(6116002)(236005)(790700001)(14454004)(5660300002)(316002)(25786009)(110136005)(54906003)(71200400001)(71190400001)(14444005)(256004)(66066001)(19627235002)(7736002)(966005)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB1891; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Wt2kh6ts4qo7J/tFBZXzG9uJ3JwAR5NkOC4k7Uc3mMG24MgPXMz9OLWFUt4ZeqSrw20vQKsbaT5wCJJRR8chz2l2beNPm0DnNsSX7puae0alq/iJs0ypWW4pr73GQ11wiFq6MxzmsjNVIhq0TXuxHUKvt23lILTXk4WeOiY22aI3ul4cxdvwuGihmkWBCzpMtzP+hS13p/xj4wUtpuzBgEDbp9fOHJbG7ghTs2dfUOxk169e/0E3PRV0PXpSzfCcFsxEd+a+Vxjwx6muMGZRMIICr61ZQ80ldMHSY97s4si1qvArV01NwQYNOIy9++F9n3JGrDwTOqaRSlhj54Uvr8ST/6PvtcZ4I6p1z6HS0WfzayxfD1P0pVxDllZjYrxG5LogK8jHQWJi3cZWi3pecH6IhsTIWZtChVwmG+5VOns= Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24028A1C7D87235BBA51E39EFE0C0AM0PR10MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 090f10bf-437f-4109-8718-08d6d5135332 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 06:47:09.5039 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB1891 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 06:48:17 -0000 --_000_AM0PR10MB24028A1C7D87235BBA51E39EFE0C0AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Panos Thank you for your thoughts and feedback. I hope my comments below explain our approach and idea better. Hendrik Von: Panos Kampanakis (pkampana) Gesendet: Donnerstag, 9. Mai 2019 20:56 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) ;= spasm@ietf.org Cc: Jim Schaad ; Russ Housley ; Fries, Steffen (CT RDA ITS) Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Understood. I don't question that CMP has it uses; I wanted to avoid a new = profile causing confusion in areas where there were other options. [Bro] I don't think the profile causes confusion. It just eases the use of = CMP. Finally, it is up to the vertical to decide which enrollment protocol = to use. As already discussed, there are use cases for different architectur= es. Features like binding to a secure transport may be an advantage for som= e use cases and a disadvantage for others, which rely on end-to-end securit= y in an environment with multiple hops. Another question. Why is this a LAMPS item? Creating a CMP profile that ap= plies to a specific vertical resembles a recent case where a draft was brou= ght to the TLS WG for V2V certificates in TLS. The TLS WG did not pick up t= he draft because of lack of interest and the narrow usecase. Why should thi= s item be part of the LAMPS charter and not ISO ICS or IEC that seem more n= atural homes? [Bro] Agreed! We target a generic lightweight profile for CMP which we woul= d like to apply to industry. Similar profiles have already been specified b= y 3GPP for telecommunication. We write the I-D independent from any vertica= l, just specifying the certificate management use cases more precisely. As described in my initial mail, there is some very limited update of CMP n= eeded to allow for the needed crypto agility and possibly to clear up some = imprecision. This is like the updates to CMC in RFC6402. We understood LAMP= S as maintainer of PKIX RFCs. As the CMP profile aims to be a general-purpose profile, I also believe tha= t this is an IETF topic. As there is much expertise in LAMPS on these topic= s, I would also appreciate, if this could be handled in this WG, too. Thanks, Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 11:02 AM To: Panos Kampanakis (pkampana) >; spasm@ietf.org Cc: Jim Schaad >; Rus= s Housley >; steffen.frie= s@siemens.com Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Panos, missed you in Prague. Steffen had a discussion on the focus of our CMP profile with Jim after the= ACE meeting in Prague. May be we did not focus enough on industrial use ca= ses. Our focus in not in the first place on constrained devices, but we bel= ieve that CMP would also work perfectly on all those devices capable to run= TLS. Currently CMP is already used in mobile networks and in rail networks.. But= we see the need to specify the needed uses cases in more detail to get int= eroperable implementations. The big advantage of CMP for industrial use is that we do not have any secu= rity requirements to the transport of the messages, since CMP messages are = self-contained and support end-to-end security. A hop-by-hop security or a= synchronous transport is not always feasible. Hendrik Von: Panos Kampanakis (pkampana) > Gesendet: Mittwoch, 8. Mai 2019 16:00 An: spasm@ietf.org; Russ Housley >; Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: Jim Schaad >; Fri= es, Steffen (CT RDA ITS) > Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens.com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_AM0PR10MB24028A1C7D87235BBA51E39EFE0C0AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Panos

 

Thank you for your thoughts and feedback.

I hope my comments below explain our approach and idea better.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampana= @cisco.com>
Gesendet: Donnerstag, 9. Mai 2019 20:56
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@sie= mens.com>; spasm@ietf.org
Cc: Jim Schaad <ietf@augustcellars.com>; Russ Housley <hous= ley@vigilsec.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens= .com>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Hendrik,

Understood. I don’t question that CMP has it = uses; I wanted to avoid a new profile causing confusion in areas where ther= e were other options.

[Bro] I don’t think the profile causes conf= usion. It just eases the use of CMP. Finally, it is up to the vertical to d= ecide which enrollment protocol to use. As already discussed, there are use= cases for different architectures. Features like binding to a secure transport may be an advantage for some use cases = and a disadvantage for others, which rely on end-to-end security in an envi= ronment with multiple hops.

Another= question.  Why is this a LAMPS item? Creating a CMP profile that appl= ies to a specific vertical resembles a recent case where a draft was brough= t to the TLS WG for V2V certificates in TLS. The TLS WG did not pick up the draft because of lack of interest and the n= arrow usecase. Why should this item be part of the LAMPS charter and not IS= O ICS or IEC that seem more natural homes?

[Bro] <= span lang=3D"EN-US">Agreed! We target a generic lightweight profile for CMP= which we would like to apply to industry. Similar profiles have already be= en specified by 3GPP for telecommunication. We write the I-D independent from any vertical, just specifying the certif= icate management use cases more precisely.

As described in my initial m= ail, there is some very limited update of CMP needed to allow for the neede= d crypto agility and possibly to clear up some imprecision. This is like th= e updates to CMC in RFC6402. We understood LAMPS as maintainer of PKIX RFCs.

As the CMP profile aims to b= e a general-purpose profile, I also believe that this is an IETF topic. As = there is much expertise in LAMPS on these topics, I would also appreciate, = if this could be handled in this WG, too.

&n= bsp;

Thanks,=
Panos

&n= bsp;

&n= bsp;

From: Spasm <spasm-bounc= es@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 11:02 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; spasm@ietf.org
Cc: Jim Schaad <ietf@au= gustcellars.com>; Russ Housley <housley@vigilsec.com>; steffen.fries@siemens.com<= br> Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Panos,

 

missed you in Prague.

 

Steffen had a discussion on the= focus of our CMP profile with Jim after the ACE meeting in Prague. May be = we did not focus enough on industrial use cases. Our focus in not in the fi= rst place on constrained devices, but we believe that CMP would also work perfectly on all those devices capable= to run TLS.

Currently CMP is already used i= n mobile networks and in rail networks.. But we see the need to specify the= needed uses cases in more detail to get interoperable implementations.

The big advantage of CMP for in= dustrial use is that we do not have any security requirements to the transp= ort of the messages, since CMP messages are self-contained and support end-= to-end security.  A hop-by-hop security or asynchronous transport is not always feasible.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampa= na@cisco.com>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm@ietf.org; Russ Housley <housley@vig= ilsec.com>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com<= /a>>
Cc: Jim Schaad <ietf@augustcellars.com>= ;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

&n= bsp;

Hi Hend= rik,

&n= bsp;

Long ti= me since we talked.

&n= bsp;

With su= ch a profile, I have a concern that what happened with SCEP, CMC, CMPv2, ES= T is likely to happen in constrained environments. Using two or more protoc= ols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation= and confuse vendors that want to pick one.

&n= bsp;

I am no= t sure I have heard a broad need for a CMP profile in ACE. If this is a sin= gle vendor need, does IETF even need to standardize this CMP profile?<= /o:p>

&n= bsp;

Panos

&n= bsp;

&n= bsp;

From: Spasm <spasm-bounc= es@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; steffen.fries@siemens.com<= br> Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on = this list we would like to spend further work on updating and profiling CMP= focusing on industrial use cases.

To get input, feedback and supp= ort from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.co= m>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <= hendrik.= brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad <ietf@august= cellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>=
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= span lang=3D"EN-US">hendrik.brockhaus@siemens.com> wrote:=

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ...

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

_______________________________________________ Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spa= sm

 

--_000_AM0PR10MB24028A1C7D87235BBA51E39EFE0C0AM0PR10MB2402EURP_-- From nobody Fri May 10 00:11:37 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90B012018F for ; Fri, 10 May 2019 00:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihC4RBpH7RRs for ; Fri, 10 May 2019 00:11:31 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50071.outbound.protection.outlook.com [40.107.5.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208B3120178 for ; Fri, 10 May 2019 00:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4JDalbOC97yDZlwFbzbGYfjrQlO1Vk5w2IqrBZzOCF8=; b=EbPURbG2p/K9JOlyhNghEH7sNNSfzauX8i4JMi0SRY72gbsrk8v2gSBLft2siu4OUJ19IhJyU47V/UE67aJSw2jxIFHfZPdHy6Irv3K0VawTq6BWbElNKgaNQ52qArdHZBsqcQdx4Ibxr4Wu3oJGQ1gRkDACzzF9FULUROHePWI= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2484.EURPRD10.PROD.OUTLOOK.COM (20.177.108.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.22; Fri, 10 May 2019 07:11:28 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1856.016; Fri, 10 May 2019 07:11:28 +0000 From: "Brockhaus, Hendrik" To: "Panos Kampanakis (pkampana)" , "Dr. Pala" , "spasm@ietf.org" Thread-Topic: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAAIqrYAAEZjLAAAHHK5gADs9lGA= Date: Fri, 10 May 2019 07:11:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.66] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89180d21-a84a-4071-b2d0-08d6d516b8a6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(49563074)(7193020); SRVR:AM0PR10MB2484; x-ms-traffictypediagnostic: AM0PR10MB2484: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0033AAD26D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(136003)(366004)(396003)(39860400002)(189003)(199004)(53754006)(486006)(2501003)(25786009)(6116002)(3846002)(52536014)(5660300002)(790700001)(64756008)(66446008)(66476007)(14444005)(73956011)(76116006)(66556008)(26005)(476003)(66616009)(2906002)(14454004)(53546011)(6506007)(7736002)(102836004)(186003)(446003)(11346002)(86362001)(478600001)(7110500001)(54896002)(6306002)(256004)(8676002)(606006)(966005)(8936002)(76176011)(81156014)(7696005)(55016002)(15650500001)(99286004)(2420400007)(81166006)(110136005)(54556002)(9686003)(99936001)(68736007)(236005)(19627235002)(66066001)(33656002)(6436002)(733005)(74316002)(71200400001)(71190400001)(53936002)(66946007)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2484; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: v56kIE6kuPwvqlMzwrx4PLrmglDFHOwkRB14LYT/QIv0eKPZCUxSO3eBiSC9VGyO2Qye+ZIoDkULFGKz17QiqIYDGOShV35rQwQtMPXzvpTfyTHjJC4cY31w5UCejlUw4wB8TqVFWCT9MQGCyyuOHotChVHNn5BVwsZTVx2w6sRh76EnixFmMUJDSAaPCO2oIJKaQetweeqyzu9DVonvXj8OlH/pZ6X/C+4qD06lEDSKJ/oKCppCAz2dsriJYJrafltLLMMvgw0GXbC6zXGmgrp9FssLmKGhUwSnNQ4zys3i4kv87qPLkuFcoRoGKz3I3TfAuPHCpDT+40HJgTjz55UBKi35MZsPig6DwlH8o0F+xrXcljuY8bZFGheJqONWWOInbe0oBH0Dj8v8zl8v5+QhArAuQvDiRVcxYcDTLZ0= Content-Type: multipart/related; boundary="_004_AM0PR10MB240238760AEFB8924995A1A6FE0C0AM0PR10MB2402EURP_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89180d21-a84a-4071-b2d0-08d6d516b8a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 07:11:28.1894 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2484 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 07:11:35 -0000 --_004_AM0PR10MB240238760AEFB8924995A1A6FE0C0AM0PR10MB2402EURP_ Content-Type: multipart/alternative; boundary="_000_AM0PR10MB240238760AEFB8924995A1A6FE0C0AM0PR10MB2402EURP_" --_000_AM0PR10MB240238760AEFB8924995A1A6FE0C0AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Panos I am not sure if I got your point right. Can you explain the difference you= make between 'Hendrik's profile' and 'CMP native'. Regardless of the very limited changes to be covered in a CMP updates I-D, = the goal of our profile is not to change CMP but to ease its use. Therefore= I would say that our profile also uses CMP native. If Max has further certificate management uses cases, not yet covered in th= e profile, I am happy to specify those together with him making use of the = existing CMP mechanisms. The purpose of the CMP profile is to tailor the features of CMP to the need= ed subset and specify this subset precisely to ease interoperable implement= ations. Hendrik Von: Spasm Im Auftrag von Panos Kampanakis (pkampa= na) Gesendet: Donnerstag, 9. Mai 2019 20:56 An: Dr. Pala ; spasm@ietf.org Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Max, > First of all, this work is something I needed to do for the EAP-CREDS (Cr= edentials Management over EAP) work (we need a simplified profile for the E= AP-CREDS to work :D). Is this the same profile proposed in Hendrik's draft or a different one? I don't question that CMP has it uses, but are the rest of the usecases you= listed out interested in using Hendrik's profile or are they just interest= ed in CMP native? Rgs, Panos From: Spasm > On Beha= lf Of Dr. Pala Sent: Wednesday, May 08, 2019 7:12 PM To: spasm@ietf.org Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, all, I too support this effort and I have few use-cases that might be relevant. First of all, this work is something I needed to do for the EAP-CREDS (Cred= entials Management over EAP) work (we need a simplified profile for the EAP= -CREDS to work :D). Another important use case we have is related to medical devices (we have b= een working with CMI for a while now): in that environment we need to use r= easonably-lived certificates (not the usual 20yrs device cert) with frequen= t renewals: when trying to select a simple protocol, CMP seemed the right c= hoice over others because of its ease of implementation and flexibility. Another use-case is within Wireless Broadband Alliance (WBA) - there, we ar= e working to define and deploy a RadSec-only deployment for a WBA-centric r= oaming infrastructure, and part of that work is to define how to deliver se= rver-side (but, in the future, also client-side via EAP-CREDS :D) certifica= tes. We are also evaluating the deployment of the same (or very similar) approac= h for the DOCSIS(r) standard (Cable Networks). I also want to point out that CMP is already used in 3gpp (the very basic v= ersion) in their SIM-based (only for an initial authentication) certificate= provisioning system (well, just the very basic of the protocol here). Last but not least, I do like CMP because it allows me to use it independen= tly from the transport protocol, which is a huge win for me (e.g., when gra= nting access to the network and connectivity is not there yet, I want to be= able to provision/manage the credentials even before the device goes onlin= e). Something like ACME, for example, it is completely useless for all my u= se-cases (and super inefficient :D). I will be happy to provide my input for the work, if needed :D Just my 2 cents... Cheers, Max On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote: Hi Panos, missed you in Prague. Steffen had a discussion on the focus of our CMP profile with Jim after the= ACE meeting in Prague. May be we did not focus enough on industrial use ca= ses. Our focus in not in the first place on constrained devices, but we bel= ieve that CMP would also work perfectly on all those devices capable to run= TLS. Currently CMP is already used in mobile networks and in rail networks.. But= we see the need to specify the needed uses cases in more detail to get int= eroperable implementations. The big advantage of CMP for industrial use is that we do not have any secu= rity requirements to the transport of the messages, since CMP messages are = self-contained and support end-to-end security. A hop-by-hop security or a= synchronous transport is not always feasible. Hendrik Von: Panos Kampanakis (pkampana) Gesendet: Mittwoch, 8. Mai 2019 16:00 An: spasm@ietf.org; Russ Housley ; Brockhaus, Hendrik (CT RDA ITS SEA-DE) Cc: Jim Schaad ; Fri= es, Steffen (CT RDA ITS) Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens.com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director [OpenCA Logo] --_000_AM0PR10MB240238760AEFB8924995A1A6FE0C0AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Panos

 

I am not sure if I got your point right. Can you exp= lain the difference you make between ‘Hendrik’s profile’ = and ‘CMP native’.

 

Regardless of the very limited changes to be covered= in a CMP updates I-D, the goal of our profile is not to change CMP but to = ease its use. Therefore I would say that our profile also uses CMP native.

If Max has further certificate management uses cases= , not yet covered in the profile, I am happy to specify those together with= him making use of the existing CMP mechanisms.

The purpose of the CMP profile is to tailor the feat= ures of CMP to the needed subset and specify this subset precisely to ease = interoperable implementations.

 

Hendrik

 

Von:<= span style=3D"color:windowtext"> Spasm <spasm-bounces@ietf.org> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Donnerstag, 9. Mai 2019 20:56
An: Dr. Pala <director@openca.org>; spasm@ietf.org
Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Max,=

&n= bsp;

> Fi= rst of all, this work is something I needed to do for the EAP-CREDS (Creden= tials Management over EAP) work (we need a simplified profile for the EAP-C= REDS to work :D).

&n= bsp;

Is this= the same profile proposed in Hendrik’s draft or a different one?

&n= bsp;

I don&#= 8217;t question that CMP has it uses, but are the rest of the usecases you = listed out interested in using Hendrik’s profile or are they just int= erested in CMP native?


Rgs,

Panos <= o:p>

&n= bsp;

F= rom: Spasm <<= a href=3D"mailto:spasm-bounces@ietf.org">spasm-bounces@ietf.org> On Behalf Of Dr. Pala
Sent: Wednesday, May 08, 2019 7:12 PM
To: spasm@ietf.org
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Hendrik, all,

I too support this effort and I have few use-cases = that might be relevant.

First of all, this work is something I needed to do= for the EAP-CREDS (Credentials Management over EAP) work (we need a simpli= fied profile for the EAP-CREDS to work :D).

Another important use case we have is related to me= dical devices (we have been working with CMI for a while now): in that envi= ronment we need to use reasonably-lived certificates (not the usual 20yrs d= evice cert) with frequent renewals: when trying to select a simple protocol, CMP seemed the right choice over = others because of its ease of implementation and flexibility.

Another use-case is within Wireless Broadband Allia= nce (WBA) - there, we are working to define and deploy a RadSec-only deploy= ment for a WBA-centric roaming infrastructure, and part of that work is to = define how to deliver server-side (but, in the future, also client-side via EAP-CREDS :D) certificates.=

We are also evaluating the deployment of the same (= or very similar) approach for the DOCSIS(r) standard (Cable Networks).=

I also want to point out that CMP is already used i= n 3gpp (the very basic version) in their SIM-based (only for an initial aut= hentication) certificate provisioning system (well, just the very basic of = the protocol here).

Last but not least, I do like CMP because it allows= me to use it independently from the transport protocol, which is a huge wi= n for me (e.g., when granting access to the network and connectivity is not= there yet, I want to be able to provision/manage the credentials even before the device goes online). Something like ACME, = for example, it is completely useless for all my use-cases (and super ineff= icient :D).

I will be happy to provide my input for the work, i= f needed :D

Just my 2 cents...

Cheers,
Max

 

On 5/8/19 9:02 AM, Brockhaus, H= endrik wrote:

Hi Panos,

 

missed you in Prague.

 

Steffen had a discussion on the= focus of our CMP profile with Jim after the ACE meeting in Prague. May be = we did not focus enough on industrial use cases. Our focus in not in the fi= rst place on constrained devices, but we believe that CMP would also work perfectly on all those devices capable= to run TLS.

Currently CMP is already used i= n mobile networks and in rail networks.. But we see the need to specify the= needed uses cases in more detail to get interoperable implementations.

The big advantage of CMP for in= dustrial use is that we do not have any security requirements to the transp= ort of the messages, since CMP messages are self-contained and support end-= to-end security.  A hop-by-hop security or asynchronous transport is not always feasible.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@au= gustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com&= gt;
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

 <= /span>

Hi Hend= rik,

 <= /span>

Long ti= me since we talked.

 <= /span>

With su= ch a profile, I have a concern that what happened with SCEP, CMC, CMPv2, ES= T is likely to happen in constrained environments. Using two or more protoc= ols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation= and confuse vendors that want to pick one.

 <= /span>

I am no= t sure I have heard a broad need for a CMP profile in ACE. If this is a sin= gle vendor need, does IETF even need to standardize this CMP profile?

 <= /span>

Panos

 <= /span>

 <= /span>

From: Spasm <spasm-bounc= es@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; steffen.fries@siemens.com<= br> Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,=

 

as discussed at IETF104 and on = this list we would like to spend further work on updating and profiling CMP= focusing on industrial use cases.

To get input, feedback and supp= ort from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@v= igilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about= two weeks away.  You would need to propose text for the charter on th= is list, and see if there are people that will review and implement.

 

Russ

 

=  

On May 3, 2019, at 4:52 AM, Bro= ckhaus, Hendrik <hendri= k.brockhaus@siemens.com> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ...

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

___________________________________= ____________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

 

=  

_______________________________________________
Spasm mailing list
Spasm@ietf.org<=
/a>
https://www.ietf.org/mailman/listinfo/spasm

--

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

3D"OpenCA

--_000_AM0PR10MB240238760AEFB8924995A1A6FE0C0AM0PR10MB2402EURP_-- --_004_AM0PR10MB240238760AEFB8924995A1A6FE0C0AM0PR10MB2402EURP_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3146; creation-date="Fri, 10 May 2019 07:11:27 GMT"; modification-date="Fri, 10 May 2019 07:11:27 GMT" Content-ID: Content-Transfer-Encoding: base64 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= --_004_AM0PR10MB240238760AEFB8924995A1A6FE0C0AM0PR10MB2402EURP_-- From nobody Fri May 10 07:49:59 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1CC312008D; Fri, 10 May 2019 07:49:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <155749979691.2835.12257508239611180195@ietfa.amsl.com> Date: Fri, 10 May 2019 07:49:56 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-08.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 14:49:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-hash-sig-08.txt Pages : 14 Date : 2019-05-10 Abstract: This document specifies the conventions for using the the HSS/LMS hash-based signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. The HSS/LMS algorithm is one form of hash-based digital signature; it is described in RFC 8554. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-08 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-hash-sig-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 10 07:52:30 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614941201E2 for ; Fri, 10 May 2019 07:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=HM0WRh+r; dkim=pass (1024-bit key) header.d=digicert.com header.b=ZwCfQxrq 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 XFi7AKTd5nMx for ; Fri, 10 May 2019 07:52:25 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355681200B2 for ; Fri, 10 May 2019 07:52:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1557499944; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:openpgp:autocrypt; bh=ga/dnAW+jXM0YFZgiyldMwyvakGT4tQyawCUlupqpqg=; b=HM0WRh+r+Kj3mWa8KeoJwd1BWqYzxndTFMc7PwTdNF/WoAHTsczrMh29k2yKheeujGDATK KkVm0BcLTkmGMvX17LSv+NLd+GGrznalYjo3C+/9ZMJbN9c++8QhB85HKUjSTPI4jYONpF XoVfXvwxV5OuptvSotHtkyxUtIwE1Po= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp2059.outbound.protection.outlook.com [104.47.34.59]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-297-_GvXfOI6NgiMoJJC_82B9w-1; Fri, 10 May 2019 10:52:22 -0400 X-MC-Unique: _GvXfOI6NgiMoJJC_82B9w-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ga/dnAW+jXM0YFZgiyldMwyvakGT4tQyawCUlupqpqg=; b=ZwCfQxrq5Abx1b8UKG1KFGU5IfSdUCd/Pjx1jwhowEr8tLufL8f1X5xbGYY8EvIB7ZkiPPSCszqeQNn060WbkxdHDvxHidTddljySTrodtgdaHBHysf3hCL9kntWXDD+y6fe/fvH5oNsGpOzQP4+ZOKfFP6Ce8iHTDd8inrycME= Received: from MWHPR14MB1533.namprd14.prod.outlook.com (10.173.233.145) by MWHPR14MB1246.namprd14.prod.outlook.com (10.173.101.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.22; Fri, 10 May 2019 14:52:19 +0000 Received: from MWHPR14MB1533.namprd14.prod.outlook.com ([fe80::fcb3:fd52:eaa1:eee3]) by MWHPR14MB1533.namprd14.prod.outlook.com ([fe80::fcb3:fd52:eaa1:eee3%3]) with mapi id 15.20.1878.022; Fri, 10 May 2019 14:52:18 +0000 From: Tim Hollebeek To: Tim Hollebeek , SPASM Thread-Topic: WG Last Call for draft-ietf-lamps-cms-mix-with-psk Thread-Index: AdT2vkCLi33zyZtBRHqpCetZGpZnKQQgZLfQ Date: Fri, 10 May 2019 14:52:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb5a3cbf-aed7-4856-65a8-08d6d557198f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:MWHPR14MB1246; x-ms-traffictypediagnostic: MWHPR14MB1246: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0033AAD26D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(136003)(346002)(366004)(189003)(199004)(66066001)(86362001)(53936002)(68736007)(99936001)(478600001)(966005)(14454004)(25786009)(6116002)(790700001)(3846002)(606006)(6436002)(54896002)(6306002)(316002)(55016002)(6246003)(9686003)(66446008)(64756008)(66556008)(66476007)(66616009)(73956011)(76116006)(66946007)(33656002)(71200400001)(8936002)(71190400001)(81166006)(8676002)(44832011)(81156014)(99286004)(74316002)(110136005)(229853002)(76176011)(11346002)(476003)(2906002)(5660300002)(7696005)(52536014)(446003)(486006)(102836004)(6506007)(53546011)(186003)(26005)(4744005)(256004)(7736002)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1246; H:MWHPR14MB1533.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: OUOrnng6mtzhiPiNkgN3QhicNpP0p3d6VWvQ0lwA9jHx1gQzIiAGQnDWWgZ4Mb0ico1ml7s/YRx4gMje1Mk6l5IrjyL2bneX6wfTxjv1Vi3BD9a7X7um2/szX5j3JIEek+jde3kT980M92NjPGKY42eZj+DTWXhHyqTymI+gp45WxzvOMS70QsBru5UUFJv2RSiywzQAapWWyIw1Q7+KxX5nm7XkCnxzC61aL84YEyjzEysY4TXNC15UpDFCkK6psvASg9KGun0zJGJmOHQ1tU8O8ecH5gVHSyQ6HWQhZEI4GWbNmri3rgoLPhcwNl7jhUxc55RDmIlOqO3tzFRCQdsRB1PMvqTWYpd/s0FKca9EIkBv7MtxxaJpnz3EVPgzX9k7rOkvJVxSDlUEmoSV4nww/PN0DXEFEYr/5HuhJOU= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_089D_01D5071E.6008A410" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb5a3cbf-aed7-4856-65a8-08d6d557198f X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 14:52:18.4680 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1246 Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 14:52:28 -0000 ------=_NextPart_000_089D_01D5071E.6008A410 Content-Type: multipart/alternative; boundary="----=_NextPart_001_089E_01D5071E.6008A410" ------=_NextPart_001_089E_01D5071E.6008A410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It appears no one has any further comments on this document, and it is ready to proceed. -Tim From: Spasm On Behalf Of Tim Hollebeek Sent: Friday, April 19, 2019 10:45 AM To: SPASM Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk This is the LAMPS WG Last Call for "Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)" . Please review the document and send your comments to the list by 6 May 2019. The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ Thanks, Tim ------=_NextPart_001_089E_01D5071E.6008A410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It appears no one has any further comments on this = document, and it is ready to proceed.

 

-Tim

 

From: Spasm = <spasm-bounces@ietf.org> On Behalf Of Tim = Hollebeek
Sent: Friday, April 19, 2019 10:45 AM
To: = SPASM <spasm@ietf.org>
Subject: [lamps] WG Last Call for = draft-ietf-lamps-cms-mix-with-psk

 

This is = the LAMPS WG Last Call for "Using Pre-Shared Key (PSK) in the = Cryptographic Message Syntax (CMS)” = <draft-ietf-lamps-cms-mix-with-psk>.  Please review the = document and send your comments to the list by 6 May = 2019.

 

The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/

 

Thanks,

 

Tim

 

------=_NextPart_001_089E_01D5071E.6008A410-- ------=_NextPart_000_089D_01D5071E.6008A410 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwNTEwMTQ1MTUxWjAvBgkqhkiG9w0BCQQxIgQg0+4CPSpniqIKso9m6WNT7dgVWxKG QSHOC0xJQh8OLTYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMkbgbR6CzUYFh7kMT0eiKSS6jyIZvcJ9xoe1I9qBAr/Ye4/abKN488FBV1LgvyQcQfeTHTW 2doyq+n7plrkle2KgEbv1ly9rr7rWO5edQdrD8Ga2dfRnXAc7Rkk8gRs47ej2IsTsCAT8jM/uRbu EvN8VKHiVjoGzubVjpjLwaGnTDHFAkiiq0Ze8pdwkPzepj78efkgMOBHpPOJ+8CsVnveHMUB1UrE VamRUi2nMp3oNFbjDEa6kldxozFyoVucee4cd5v9wGp0JtMI5glGNEvvpzGJDm3v60maATbcjeYq pXbxe+B+qppe2K9qua/eQAn0ehVw/5bb0z99X3I9wtAAAAAAAAA= ------=_NextPart_000_089D_01D5071E.6008A410-- From nobody Fri May 10 07:53:16 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0040E1201EA for ; Fri, 10 May 2019 07:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=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 Y35j_ktWQR14 for ; Fri, 10 May 2019 07:53:12 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316AB1200B2 for ; Fri, 10 May 2019 07:52:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 384F5300AA0 for ; Fri, 10 May 2019 10:33:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BCHuwZtLcCL7 for ; Fri, 10 May 2019 10:33:37 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 12581300471 for ; Fri, 10 May 2019 10:33:37 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Fri, 10 May 2019 10:52:53 -0400 References: <155749979691.2835.12257508239611180195@ietfa.amsl.com> To: SPASM In-Reply-To: <155749979691.2835.12257508239611180195@ietfa.amsl.com> Message-Id: <52AE04BE-7747-4658-9413-1B54D9028AA9@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [lamps] I-D Action: draft-ietf-lamps-cms-hash-sig-08.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 14:53:14 -0000 This update resolves comments received on Section 1.3. This update also changes the [HASHSIG] reference to point to RFC 8554. Russ > On May 10, 2019, at 10:49 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Limited Additional Mechanisms for = PKIX and SMIME WG of the IETF. >=20 > Title : Use of the HSS/LMS Hash-based Signature = Algorithm in the Cryptographic Message Syntax (CMS) > Author : Russ Housley > Filename : draft-ietf-lamps-cms-hash-sig-08.txt > Pages : 14 > Date : 2019-05-10 >=20 > Abstract: > This document specifies the conventions for using the the HSS/LMS > hash-based signature algorithm with the Cryptographic Message Syntax > (CMS). In addition, the algorithm identifier and public key syntax > are provided. The HSS/LMS algorithm is one form of hash-based > digital signature; it is described in RFC 8554. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-hash-sig/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lamps-cms-hash-sig-08 > https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-hash-sig-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lamps-cms-hash-sig-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 10 08:00:54 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835D712024B for ; Fri, 10 May 2019 08:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAOu4kUN2Wik for ; Fri, 10 May 2019 08:00:50 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6961201ED for ; Fri, 10 May 2019 08:00:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 909D4300A1C for ; Fri, 10 May 2019 10:41:32 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lCgCkN9gRumT for ; Fri, 10 May 2019 10:41:31 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 07D8F300471; Fri, 10 May 2019 10:41:31 -0400 (EDT) From: Russ Housley Message-Id: <1A8C21B1-33D1-4E31-94F8-E9553964D540@vigilsec.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8A9E4E42-BCEF-4794-A02D-4CBA70C65652"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Fri, 10 May 2019 11:00:47 -0400 In-Reply-To: Cc: SPASM To: Tim Hollebeek References: X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 15:00:53 -0000 --Apple-Mail=_8A9E4E42-BCEF-4794-A02D-4CBA70C65652 Content-Type: multipart/alternative; boundary="Apple-Mail=_920D583C-5F61-41CB-8094-D79E6FE8EB63" --Apple-Mail=_920D583C-5F61-41CB-8094-D79E6FE8EB63 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The only comment that I received is to add at the top of = the ASN.1 module and at the bottom of the ASN.1 module. I = will do that now. Russ > On May 10, 2019, at 10:52 AM, Tim Hollebeek = wrote: >=20 > It appears no one has any further comments on this document, and it is = ready to proceed. > =20 > -Tim > =20 > From: Spasm > = On Behalf Of Tim Hollebeek > Sent: Friday, April 19, 2019 10:45 AM > To: SPASM > > Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk > =20 > This is the LAMPS WG Last Call for "Using Pre-Shared Key (PSK) in the = Cryptographic Message Syntax (CMS)=E2=80=9D = . Please review the document and = send your comments to the list by 6 May 2019. > =20 > The datatracker page for the document is = https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ = > =20 > Thanks, > =20 > Tim --Apple-Mail=_920D583C-5F61-41CB-8094-D79E6FE8EB63 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The = only comment that I received is to add <CODE BEGINS> at the top of = the ASN.1 module and <CODE ENDS> at the bottom of the ASN.1 = module.  I will do that now.

Russ


On May = 10, 2019, at 10:52 AM, Tim Hollebeek <tim.hollebeek@digicert.com> wrote:

It = appears no one has any further comments on this document, and it is = ready to proceed.
 
-Tim
 
From: Spasm <spasm-bounces@ietf.org> On Behalf = Of Tim = Hollebeek
Sent: Friday, April 19, 2019 = 10:45 AM
To: SPASM <spasm@ietf.org>
Subject: [lamps] WG Last Call for = draft-ietf-lamps-cms-mix-with-psk
 
This is the LAMPS WG Last Call for "Using Pre-Shared Key = (PSK) in the Cryptographic Message Syntax (CMS)=E2=80=9D = <draft-ietf-lamps-cms-mix-with-psk>.  Please review the = document and send your comments to the list by 6 May 2019.
 
The = datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-= psk/
 
Thanks,
 
Tim

= --Apple-Mail=_920D583C-5F61-41CB-8094-D79E6FE8EB63-- --Apple-Mail=_8A9E4E42-BCEF-4794-A02D-4CBA70C65652 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCyEw ggUzMIIEG6ADAgECAhBXG2+j5p4WC1fo6lHciFftMA0GCSqGSIb3DQEBCwUAMIGXMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODA2MjUwMDAwMDBaFw0xOTA2MjUyMzU5 NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGhvdXNsZXlAdmlnaWxzZWMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEApxLwi8D2JgVTZ+YNvnixkXxtbSTKKHCm0MyXlpqN59qybHNXkm2w lAzm5+AX1NcPk7DLGlrz+48B8jsrJjdnpHpKeFwHfcoYIiwJJm+hdvVO2nL68nW/oliUysde+knU 1yWbM8fD8i3XWz3DpUvU8G3IGz5cxh1MzOT/8mkgpWmfp/WxaIRlTrYnCo49SakOux7h+8dHzabU Uukr+LatyVjakES29gw73o+exeu7lcTmShfr4Jsgq+t4IkwWZtIHQRtboAjAY91FMdDwAl677hf9 gcJ86eh7qX1KZ6uzMf4fjsxw3V81WYlQ8T9QSh06faTKnStIwPu6xvk82Bp6FQIDAQABo4IB6jCC AeYwHwYDVR0jBBgwFoAUgq9sjPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFF0Zu7HtPJ6vLPYl 9I337Y98QYnFMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUF BwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIx AQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0f BFMwUTBPoE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVu dGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20w HwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcNAQELBQADggEBAH9WEE7E 61zha2wG5mBhzoe/gRDykpC/ubMQ7CoCeVhnystE18ZQSHTkOlJsQOwSRs//khBvw/P19xgCkWL+ kQWwJN8JBdP0cDamaEj4kqcvQzq0gGJoDxsr2SusZkzdKJn2pkPL2Djmurx3BEfWv1oN+z27n7dF +vv74SzoBHb92ShoZb+52XazmqFjCJDXR1UjJhaiQerxou+JRku04E1njtTR/CbLtFScgq767s5p GnLA0E5QDcVGrWLkVzXQKV49gFXDzXa5ChG9v/KOulsHqJH0KwcEsA3taVb3QDb8CNm3MboE24xp ZmNSHHd8YquMD4aw7o0+bzjlu+u18+4wggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0G CSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMi Q09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAx MDkyMzU5NTlaMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+ nKcxLqf2NHbZhGra0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQ yDMqVaVUkbIr5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWW Co63OTTqRvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJ QaDaElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEA AaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM +MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20v Q09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsG AQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAk BggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4 XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7Hto SmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7 I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4 o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu 6t99p17bTbY7+1RTWBviN9YJzK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QI hhmiNOr84JHoy+fNLpfvYc/Q9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv 9mj2PMnXoc7mbrS22XUSeTwxCTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIv xqith7DoJC91WJ8Lce3CVJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/ vOYRUM1cWcef20Wkyk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGC A8cwggPDAgEBMIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0 Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQVxtv o+aeFgtX6OpR3IhX7TANBglghkgBZQMEAgEFAKCCAeswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTkwNTEwMTUwMDQ4WjAvBgkqhkiG9w0BCQQxIgQgizmpnBaZYFtr dFostaxAzDtJPXCcKvBbhrBRplRmLKUwgb0GCSsGAQQBgjcQBDGBrzCBrDCBlzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0EgQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEFcbb6PmnhYLV+jqUdyIV+0wgb8GCyqGSIb3DQEJ EAILMYGvoIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQVxtvo+ae FgtX6OpR3IhX7TANBgkqhkiG9w0BAQEFAASCAQAW1X4wzoKJXnaU7UrJwH9cx7MWBzM5BzWjxn0b WT7QPkpW1m876VZ86aWczSrR2OmHMG+ZskVfj5bzf9aBbT+OX0CSrUBgPzHLavnPHytaEalHxAcU jGA1U+s8ONjKpfA7EoJPFN92Rs9Qg5vB3vVlj+/4j6MGu4JJgue3f9TEacqu9t2GXkQBjqjIgTXh qUtPXyDdfD97tvm0zqby/tbts8bLKgzpqIcDtY4X94n0DX8Ie+Z56QI1H2FzSmcRqEHlZGQlFMpa obz2uOmc6unXgEmsaGNiei8dQN2F8iYTabVEVZVbSMczSq1ytAs+tnAj/4OvZJZrQncIX7R5izhy AAAAAAAA --Apple-Mail=_8A9E4E42-BCEF-4794-A02D-4CBA70C65652-- From nobody Fri May 10 08:02:44 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF904120077; Fri, 10 May 2019 08:02:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <155750055583.2954.9823288656897783387@ietfa.amsl.com> Date: Fri, 10 May 2019 08:02:35 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-cms-mix-with-psk-04.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 15:02:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS) Author : Russ Housley Filename : draft-ietf-lamps-cms-mix-with-psk-04.txt Pages : 29 Date : 2019-05-10 Abstract: The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support the new algorithms, if the existing syntax does not accommodate them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-cms-mix-with-psk-04 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-cms-mix-with-psk-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-cms-mix-with-psk-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 10 10:28:56 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3A6120088 for ; Fri, 10 May 2019 10:28:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.5 X-Spam-Level: X-Spam-Status: No, score=-12.5 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mCcQbBgV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Y9X2U4aW 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 0SyKKnu_baxu for ; Fri, 10 May 2019 10:28:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AF5D120074 for ; Fri, 10 May 2019 10:28:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41008; q=dns/txt; s=iport; t=1557509331; x=1558718931; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=gyo4feKqyahyfxS6+BTEaz9ZH6l5bi+vkl8dBtPa7WQ=; b=mCcQbBgVYwYX19UzkNsaZGLv5+Y45TNkrOWgPZ6dtVOVVijfAsf016p6 ssVGnVkTPwiyH3l9Izu74w8lnNZjlZIT6v78N+9UMzbOndXCE9z+7xvp8 TXBZhwSOwa+zDgxgTT/JRAVRSH7fACbmLILKIxDCFN0jOsBMOyKiSIIvy k=; X-Files: image001.png : 3146 IronPort-PHdr: =?us-ascii?q?9a23=3Ai8bISRYLiouYauiR+O3XwQ7/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavybCU/BM1EXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAABGtNVc/51dJa1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZYEPLyQsA2lVIAQLKIVwgWgDjn6CV5clgUKBEANQBAIHAQE?= =?us-ascii?q?BCQECAQEYAQkLAgEBgQVdgl4CggsjOBMBAwEBBAEBAgEEbRwMhUoBAQEDAQE?= =?us-ascii?q?BAw0TCAESAQEsBAgECwIBCBEEAQEGAQEBGAECBAcCBRABDgELFAkIAgQBEQE?= =?us-ascii?q?GAgYQBIJ7BAKBagMODwEOoQUCgTWIX4IgH4JaAQEFgTIBg00DFYIIBwMGgTK?= =?us-ascii?q?KDIFDF4FAP4ERRoFOUC4+gmEBAQIYgQsJAQsHAQkYFRYJgwaCBCKLHxEkhlm?= =?us-ascii?q?IDoRXgjmFJGUJAoIJhR4BgQCMVYITk1aIdYIkgRiBIpNhAgQCBAUCDgEBBYF?= =?us-ascii?q?mIQ1ZcXAVO4JsE4FYJAwXFIM4hRSFP3IBAQEBgSWMfg8XgT1vAQE?= X-IronPort-AV: E=Sophos;i="5.60,454,1549929600"; d="png'150?scan'150,208,217,150";a="556746765" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 May 2019 17:28:49 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x4AHSn3j024087 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 10 May 2019 17:28:49 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 May 2019 12:28:48 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 10 May 2019 12:28:48 -0500 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 10 May 2019 13:28:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tcB4lHy+K9MCOy2izrgocbmeqHo6f6cuUTOqX4ZGJlE=; b=Y9X2U4aW8QZvLONPz7F31Z5T/TWQww5pjB0hLYkfwpAxyVx3oCk7dbGLhtnufPIFhNsmVTvSLZCnLLa3EhxOOypnPbL9WrxOnPsCRvMn0YIzh0FRfoeD0DhmFNc9MyWOk/MPKU1/2pgmai02omG/RQj5HJOqga63HlXvMgvWLKY= Received: from MWHPR11MB1838.namprd11.prod.outlook.com (10.175.53.141) by MWHPR11MB1614.namprd11.prod.outlook.com (10.172.54.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.22; Fri, 10 May 2019 17:28:45 +0000 Received: from MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::4964:5495:9121:8f12]) by MWHPR11MB1838.namprd11.prod.outlook.com ([fe80::4964:5495:9121:8f12%7]) with mapi id 15.20.1878.022; Fri, 10 May 2019 17:28:45 +0000 From: "Panos Kampanakis (pkampana)" To: "Brockhaus, Hendrik" , "Dr. Pala" , "spasm@ietf.org" Thread-Topic: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAAIqrYAAEZjLAAAHHK5gADs9lGAAFiBsoA== Date: Fri, 10 May 2019 17:28:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1002::276] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c2a48b56-b302-47d6-7e5d-08d6d56cf4b2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:MWHPR11MB1614; x-ms-traffictypediagnostic: MWHPR11MB1614: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0033AAD26D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(39860400002)(366004)(376002)(136003)(199004)(189003)(53754006)(53936002)(6246003)(33656002)(15650500001)(2420400007)(14444005)(8936002)(486006)(25786009)(81156014)(81166006)(8676002)(68736007)(71200400001)(71190400001)(256004)(2501003)(7736002)(76176011)(6506007)(53546011)(99286004)(7696005)(102836004)(7110500001)(2906002)(790700001)(6116002)(476003)(11346002)(446003)(186003)(6306002)(110136005)(236005)(74316002)(52536014)(46003)(86362001)(5660300002)(6436002)(606006)(733005)(54896002)(14454004)(9686003)(73956011)(54556002)(76116006)(316002)(66946007)(66446008)(55016002)(64756008)(966005)(66556008)(66616009)(66476007)(99936001)(229853002)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1614; H:MWHPR11MB1838.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: T3dRR8Mqdu36sl1XCIj4+BhnyVFl0+figEML0MHLOoBpEDxD2A/v+p2CMX7Jh/u+gEuM2j6uwO3rkDs5ClCinxx1T9PuAbLZ5FcM3gvYKd6xixhFiDMLw3k9XyStaVUogz2RZfxOJxmubcUQMUcqYZU3IiV9G5Vvc4jSVPCHFU6uAe/vQ6o7xef+yn0bIEhV19rO/SjVBGpuwQ1wv7EJzLXyJHnD1Ac+KLeSypPLQupWNZROW1Qp9NJnHb8OhoUx0tOxoNRubtMAsfEbFOYef1Cs8h7fT2wlLgdjqR/04wIOc0Q3xsna3FYVSVk728Y7POzQE+1edeA582Q8xhgW5Eus6SutEoIE3stmRaPzQ/7A/h9DNpeQZaa68doSfT2o1A8QUhqwuboKxa4nPaNIZPRyZYRtrG5liCk1Wvwy09I= Content-Type: multipart/related; boundary="_004_MWHPR11MB18385B30D58DA4B4224C8A57C90C0MWHPR11MB1838namp_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c2a48b56-b302-47d6-7e5d-08d6d56cf4b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2019 17:28:45.6044 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1614 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2019 17:28:55 -0000 --_004_MWHPR11MB18385B30D58DA4B4224C8A57C90C0MWHPR11MB1838namp_ Content-Type: multipart/alternative; boundary="_000_MWHPR11MB18385B30D58DA4B4224C8A57C90C0MWHPR11MB1838namp_" --_000_MWHPR11MB18385B30D58DA4B4224C8A57C90C0MWHPR11MB1838namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > tailor the features of CMP to the needed subset and specify this subset p= recisely to ease interoperable implementations You are creating a profile for CMP with a subset of its feature and minor u= pdates to the protocol itself. I was not sure if the subset you need for in= dustrial automation will match exactly the simplified profile Max needs for= the EAP-CREDS. From: Spasm On Behalf Of Brockhaus, Hendrik Sent: Friday, May 10, 2019 3:11 AM To: Panos Kampanakis (pkampana) ; Dr. Pala ; spasm@ietf.org Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Panos I am not sure if I got your point right. Can you explain the difference you= make between 'Hendrik's profile' and 'CMP native'. Regardless of the very limited changes to be covered in a CMP updates I-D, = the goal of our profile is not to change CMP but to ease its use. Therefore= I would say that our profile also uses CMP native. If Max has further certificate management uses cases, not yet covered in th= e profile, I am happy to specify those together with him making use of the = existing CMP mechanisms. The purpose of the CMP profile is to tailor the features of CMP to the need= ed subset and specify this subset precisely to ease interoperable implement= ations. Hendrik Von: Spasm > Im Auftr= ag von Panos Kampanakis (pkampana) Gesendet: Donnerstag, 9. Mai 2019 20:56 An: Dr. Pala >; spasm@ietf.= org Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Max, > First of all, this work is something I needed to do for the EAP-CREDS (Cr= edentials Management over EAP) work (we need a simplified profile for the E= AP-CREDS to work :D). Is this the same profile proposed in Hendrik's draft or a different one? I don't question that CMP has it uses, but are the rest of the usecases you= listed out interested in using Hendrik's profile or are they just interest= ed in CMP native? Rgs, Panos From: Spasm > On Beha= lf Of Dr. Pala Sent: Wednesday, May 08, 2019 7:12 PM To: spasm@ietf.org Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, all, I too support this effort and I have few use-cases that might be relevant. First of all, this work is something I needed to do for the EAP-CREDS (Cred= entials Management over EAP) work (we need a simplified profile for the EAP= -CREDS to work :D). Another important use case we have is related to medical devices (we have b= een working with CMI for a while now): in that environment we need to use r= easonably-lived certificates (not the usual 20yrs device cert) with frequen= t renewals: when trying to select a simple protocol, CMP seemed the right c= hoice over others because of its ease of implementation and flexibility. Another use-case is within Wireless Broadband Alliance (WBA) - there, we ar= e working to define and deploy a RadSec-only deployment for a WBA-centric r= oaming infrastructure, and part of that work is to define how to deliver se= rver-side (but, in the future, also client-side via EAP-CREDS :D) certifica= tes. We are also evaluating the deployment of the same (or very similar) approac= h for the DOCSIS(r) standard (Cable Networks). I also want to point out that CMP is already used in 3gpp (the very basic v= ersion) in their SIM-based (only for an initial authentication) certificate= provisioning system (well, just the very basic of the protocol here). Last but not least, I do like CMP because it allows me to use it independen= tly from the transport protocol, which is a huge win for me (e.g., when gra= nting access to the network and connectivity is not there yet, I want to be= able to provision/manage the credentials even before the device goes onlin= e). Something like ACME, for example, it is completely useless for all my u= se-cases (and super inefficient :D). I will be happy to provide my input for the work, if needed :D Just my 2 cents... Cheers, Max On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote: Hi Panos, missed you in Prague. Steffen had a discussion on the focus of our CMP profile with Jim after the= ACE meeting in Prague. May be we did not focus enough on industrial use ca= ses. Our focus in not in the first place on constrained devices, but we bel= ieve that CMP would also work perfectly on all those devices capable to run= TLS. Currently CMP is already used in mobile networks and in rail networks.. But= we see the need to specify the needed uses cases in more detail to get int= eroperable implementations. The big advantage of CMP for industrial use is that we do not have any secu= rity requirements to the transport of the messages, since CMP messages are = self-contained and support end-to-end security. A hop-by-hop security or a= synchronous transport is not always feasible. Hendrik Von: Panos Kampanakis (pkampana) Gesendet: Mittwoch, 8. Mai 2019 16:00 An: spasm@ietf.org; Russ Housley ; Brockhaus, Hendrik (CT RDA ITS SEA-DE) Cc: Jim Schaad ; Fri= es, Steffen (CT RDA ITS) Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens.com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director [OpenCA Logo] --_000_MWHPR11MB18385B30D58DA4B4224C8A57C90C0MWHPR11MB1838namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> tailor the features of CMP to the needed subset and = specify this subset precisely to ease interoperable implementations<= span style=3D"color:#1F497D">

 

You are creating a pro= file for CMP with a subset of its feature and minor updates to the protocol= itself. I was not sure if the subset you need for industrial automation wi= ll match exactly the simplified profile Max needs for the EAP-CREDS.

 

 

 

From:= Spasm <spasm-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Friday, May 10, 2019 3:11 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; Dr. Pala= <director@openca.org>; spasm@ietf.org
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Pano= s

&n= bsp;

I am not sure if I = got your point right. Can you explain the difference you make between ̵= 6;Hendrik’s profile’ and ‘CMP native’.

 

Regardless of the v= ery limited changes to be covered in a CMP updates I-D, the goal of our pro= file is not to change CMP but to ease its use. Therefore I would say that o= ur profile also uses CMP native.

If Max has further = certificate management uses cases, not yet covered in the profile, I am hap= py to specify those together with him making use of the existing CMP mechan= isms.

The purpose of the = CMP profile is to tailor the features of CMP to the needed subset and speci= fy this subset precisely to ease interoperable implementations.<= /span>

 

Hendrik<= /span>

 

Von:= Spasm <spasm-bounces@ietf.org> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Donnerstag, 9. Mai 2019 20:56
An: Dr. Pala <director@ope= nca.org>; spasm@ietf.org
Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Max,

 

> First of all, thi= s work is something I needed to do for the EAP-CREDS (Credentials Managemen= t over EAP) work (we need a simplified profile for the EAP-CREDS to work :D= ).

 

Is this the same profi= le proposed in Hendrik’s draft or a different one?

 

I don’t question= that CMP has it uses, but are the rest of the usecases you listed out inte= rested in using Hendrik’s profile or are they just interested in CMP = native?


Rgs,

Panos

 

From:= Spasm <spasm-bounces@ietf.org> On Behalf Of Dr. Pala
Sent: Wednesday, May 08, 2019 7:12 PM
To: spasm@ietf.org
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Hendrik, all,

I too support this effort and I have few use-cases that might be relevan= t.

First of all, this work is something I needed to do for the EAP-CREDS (C= redentials Management over EAP) work (we need a simplified profile for the = EAP-CREDS to work :D).

Another important use case we have is related to medical devices (we hav= e been working with CMI for a while now): in that environment we need to us= e reasonably-lived certificates (not the usual 20yrs device cert) with freq= uent renewals: when trying to select a simple protocol, CMP seemed the right choice over others because of its = ease of implementation and flexibility.

Another use-case is within Wireless Broadband Alliance (WBA) - there, we= are working to define and deploy a RadSec-only deployment for a WBA-centri= c roaming infrastructure, and part of that work is to define how to deliver= server-side (but, in the future, also client-side via EAP-CREDS :D) certificates.

We are also evaluating the deployment of the same (or very similar) appr= oach for the DOCSIS(r) standard (Cable Networks).

I also want to point out that CMP is already used in 3gpp (the very basi= c version) in their SIM-based (only for an initial authentication) certific= ate provisioning system (well, just the very basic of the protocol here).

Last but not least, I do like CMP because it allows me to use it indepen= dently from the transport protocol, which is a huge win for me (e.g., when = granting access to the network and connectivity is not there yet, I want to= be able to provision/manage the credentials even before the device goes online). Something like ACME, for = example, it is completely useless for all my use-cases (and super inefficie= nt :D).

I will be happy to provide my input for the work, if needed :D

Just my 2 cents...

Cheers,
Max

 

On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote:

Hi Panos,

 

missed you in Prague.

 

Steffen had a discussion on the focus of our CMP pro= file with Jim after the ACE meeting in Prague. May be we did not focus enou= gh on industrial use cases. Our focus in not in the first place on constrai= ned devices, but we believe that CMP would also work perfectly on all those devices capable to run TLS.

Currently CMP is already used in mobile networks and= in rail networks.. But we see the need to specify the needed uses cases in= more detail to get interoperable implementations.

The big advantage of CMP for industrial use is that = we do not have any security requirements to the transport of the messages, = since CMP messages are self-contained and support end-to-end security. &nbs= p;A hop-by-hop security or asynchronous transport is not always feasible.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@au= gustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com&= gt;
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

 

Hi Hendrik,

 

Long time since we tal= ked.

 

With such a profile, I= have a concern that what happened with SCEP, CMC, CMPv2, EST is likely to = happen in constrained environments. Using two or more protocols (EST-coaps,= a CMP profile over different transports, and others) that do similar things would lead to fragmentation and confuse= vendors that want to pick one.

 

I am not sure I have h= eard a broad need for a CMP profile in ACE. If this is a single vendor need= , does IETF even need to standardize this CMP profile?

 

Panos

 

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; steffen.fries@siemens.com<= br> Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on this list we would li= ke to spend further work on updating and profiling CMP focusing on industri= al use cases.

To get input, feedback and support from LAMPS we pro= pose the following charter text.

 

= As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in industrial environments it needs to be enhanced to more e= fficiently support of industrial use cases, crypto agility and specific com= munication relations on the one hand and profiled to the necessary function= ality on the other hand to ease application and to better facilitate interoperable implementation. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.c= om> wrote:

 

Hi= all

&n= bsp;

Re= ferring to the Email thread 'Seeking guidance on proceeding with question f= rom IETF-104 presentation on lightweight CMP profile' and to the outcome of= the WG meeting, we want to summarize the current state of the discussion.

Th= e discussion we had with Jim motivate a split of the current draft into a C= MP Updates and a CMP Profile document. The update of CMP is needed because = we identified at least two point where a change to CMP is needed:

- = Change the type of encryptedCert from EncryptedValue to EncryptedKey for EC= C and post-quantum algorithm support

- = Extend the RootCAUpdate announcement message to e request/response message = to enable requesting the update from the client side

Th= e remaining points from the initial email were seen as profiling topic and = would therefore be handled in the CMP Profile document....

&n= bsp;

@R= uss, how do you see the status of the current re-chartering process? Would = you support to add both, or at least the CMP Updates, activities under the = revised charter?

&n= bsp;

- = Hendrik

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

 

 

_=
______________________________________________
S=
pasm mailing list
<=
a href=3D"mailto:Spasm@ietf.org">Spasm@ietf.org
<=
a href=3D"https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F=
%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=3D02%7C01%7Chendrik.b=
rockhaus%40siemens.com%7C00fbc3cf35894e89e47108d6d4b001e6%7C38ae3bcd95794fd=
4addab42e1495d55a%7C1%7C0%7C636930249744670853&sdata=3DG3ur8N2%2Bi8oVhv=
kozjjwNwZwU%2BoGUr%2FSvM335L81bmw%3D&reserved=3D0">https://www.ietf.org=
/mailman/listinfo/spasm

--

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

3D"OpenCA

--_000_MWHPR11MB18385B30D58DA4B4224C8A57C90C0MWHPR11MB1838namp_-- --_004_MWHPR11MB18385B30D58DA4B4224C8A57C90C0MWHPR11MB1838namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3146; creation-date="Fri, 10 May 2019 17:28:45 GMT"; modification-date="Fri, 10 May 2019 17:28:45 GMT" Content-ID: Content-Transfer-Encoding: base64 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= --_004_MWHPR11MB18385B30D58DA4B4224C8A57C90C0MWHPR11MB1838namp_-- From nobody Sat May 11 13:54:29 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7762B120045; Sat, 11 May 2019 13:54:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155760806741.23982.17913134945724564971.idtracker@ietfa.amsl.com> Date: Sat, 11 May 2019 13:54:27 -0700 Archived-At: Subject: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2019 20:54:28 -0000 Barry Leiba has entered the following ballot position for charter-ietf-lamps-03-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- No objection to the list of work items, but maybe it’s time to rename this “AMPS”, as “L” doesn’t seem to apply any more. From nobody Sun May 12 23:31:03 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5025120098 for ; Sun, 12 May 2019 23:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXe18kaWa4B1 for ; Sun, 12 May 2019 23:30:57 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60042.outbound.protection.outlook.com [40.107.6.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A744312007A for ; Sun, 12 May 2019 23:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B0nMg1DmnUpMwpu+YQQQxLOJJxPu4B9++NOxdpe0Af8=; b=iDdn/LLxfKvTncODDtFrS8CZVtqIDNXyed9+5Q8sjGOg20wKWYtID8QoLs5tryfRdEGxFx1UER0kZG3DJnBNMHBY8Av2bpdxDmVHrmlx6Jn1a46GWdkKTOmH+vGED2e8GQNtAe5LCmO/F/JTPnmVpjFFnA6tn8VkXHvl/g1AjVs= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2721.EURPRD10.PROD.OUTLOOK.COM (20.178.117.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1878.22; Mon, 13 May 2019 06:30:52 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1878.024; Mon, 13 May 2019 06:30:52 +0000 From: "Brockhaus, Hendrik" To: "Panos Kampanakis (pkampana)" , "Dr. Pala" , "spasm@ietf.org" Thread-Topic: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAAIqrYAAEZjLAAAHHK5gADs9lGAAFiBsoAB/OY/g Date: Mon, 13 May 2019 06:30:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.77] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 11e61763-431e-4d9d-de12-08d6d76c8c47 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(49563074)(7193020); SRVR:AM0PR10MB2721; x-ms-traffictypediagnostic: AM0PR10MB2721: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0036736630 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(396003)(136003)(346002)(53754006)(189003)(199004)(7696005)(66066001)(76176011)(33656002)(2501003)(15650500001)(2420400007)(68736007)(966005)(478600001)(14454004)(99286004)(110136005)(606006)(74316002)(99936001)(11346002)(71190400001)(71200400001)(476003)(486006)(8676002)(236005)(54896002)(446003)(3846002)(55016002)(81166006)(81156014)(6116002)(316002)(733005)(9686003)(7110500001)(30864003)(6306002)(54556002)(6436002)(19627235002)(25786009)(7736002)(5660300002)(2906002)(102836004)(53546011)(86362001)(6506007)(186003)(26005)(790700001)(14444005)(256004)(53946003)(52536014)(66446008)(66946007)(66616009)(66476007)(66556008)(64756008)(53936002)(73956011)(8936002)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2721; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6OIk9R1r/HoeAfugj8BO1C1ikjYJ4pOl3l4g3S5rLkdEFie6uytUbrAUc/NwlEaqdVChl5vV9P6mIRiIZItoHi/vkDh8B0Ql4HQb7t821V5nP7Yz9aJTpeRT0a/7njOeMnHYBFHYqCh2kVEhgg0h78YUZp/5i8yRL2AMVMk0+zBvznl3M/tIX697RDggJkMAoS8hOnBBcfmnOxm08votthSKBKa4G8CQ9gs8RXm1y1mqQES/R9PSZSboFxU6VCBuVR99dxXweYc/dS9DejfQc3cyMyUeC/PWRNAp3iHyWCLmKnFOuKmuxsbE6xp0i1+ETPoC09AhFE9v4tBy74HSxPLotj5Tz4PMimkolfp6IUYdlexKhVmwitzi5hVQT/1DGgfBiymMFmgV9/iFzIKEGcZD/h0GcTaYHQ0zMqXdByM= Content-Type: multipart/related; boundary="_004_AM0PR10MB240200E9F587DADDDE018ACCFE0F0AM0PR10MB2402EURP_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11e61763-431e-4d9d-de12-08d6d76c8c47 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2019 06:30:52.8074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2721 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2019 06:31:01 -0000 --_004_AM0PR10MB240200E9F587DADDDE018ACCFE0F0AM0PR10MB2402EURP_ Content-Type: multipart/alternative; boundary="_000_AM0PR10MB240200E9F587DADDDE018ACCFE0F0AM0PR10MB2402EURP_" --_000_AM0PR10MB240200E9F587DADDDE018ACCFE0F0AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OK, understood. Thank you for the clarification. Let us see what is finally needed for Max use cases. See an explanation on the needed CMP update inline. Von: Panos Kampanakis (pkampana) Gesendet: Freitag, 10. Mai 2019 19:29 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) ;= Dr. Pala ; spasm@ietf.org Betreff: RE: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) > tailor the features of CMP to the needed subset and specify this subset p= recisely to ease interoperable implementations You are creating a profile for CMP with a subset of its feature and minor u= pdates to the protocol itself. I was not sure if the subset you need for in= dustrial automation will match exactly the simplified profile Max needs for= the EAP-CREDS. [Bro] As discussed with Jim, the goal is to keep the very limited changes t= o CMP in a separate I-D and do the tailoring in the profile document. Finally there is only one real change to better support ECC and post-quantu= m algorithms in CMP. --> Change EncryptedValue to EncryptedKey to also support EnvelopedData. As EncryptedKey is a choice of EncryptedValue and EnvelopedData this change= should be backward compatible. Therefore I do not see much problems there. Everything else are more clarification topics that are of general value for= CMP from my point of view. This is why I would suggest to put them into th= e CMP updates document, but they could also be shifted to the CMP profile. = This can be discussed and decides in the WG then. From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Friday, May 10, 2019 3:11 AM To: Panos Kampanakis (pkampana) >; Dr. Pala >; spasm@iet= f.org Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Panos I am not sure if I got your point right. Can you explain the difference you= make between 'Hendrik's profile' and 'CMP native'. Regardless of the very limited changes to be covered in a CMP updates I-D, = the goal of our profile is not to change CMP but to ease its use. Therefore= I would say that our profile also uses CMP native. If Max has further certificate management uses cases, not yet covered in th= e profile, I am happy to specify those together with him making use of the = existing CMP mechanisms. The purpose of the CMP profile is to tailor the features of CMP to the need= ed subset and specify this subset precisely to ease interoperable implement= ations. Hendrik Von: Spasm > Im Auftr= ag von Panos Kampanakis (pkampana) Gesendet: Donnerstag, 9. Mai 2019 20:56 An: Dr. Pala >; spasm@ietf.= org Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Max, > First of all, this work is something I needed to do for the EAP-CREDS (Cr= edentials Management over EAP) work (we need a simplified profile for the E= AP-CREDS to work :D). Is this the same profile proposed in Hendrik's draft or a different one? I don't question that CMP has it uses, but are the rest of the usecases you= listed out interested in using Hendrik's profile or are they just interest= ed in CMP native? Rgs, Panos From: Spasm > On Beha= lf Of Dr. Pala Sent: Wednesday, May 08, 2019 7:12 PM To: spasm@ietf.org Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightw= eight profile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, all, I too support this effort and I have few use-cases that might be relevant. First of all, this work is something I needed to do for the EAP-CREDS (Cred= entials Management over EAP) work (we need a simplified profile for the EAP= -CREDS to work :D). Another important use case we have is related to medical devices (we have b= een working with CMI for a while now): in that environment we need to use r= easonably-lived certificates (not the usual 20yrs device cert) with frequen= t renewals: when trying to select a simple protocol, CMP seemed the right c= hoice over others because of its ease of implementation and flexibility. Another use-case is within Wireless Broadband Alliance (WBA) - there, we ar= e working to define and deploy a RadSec-only deployment for a WBA-centric r= oaming infrastructure, and part of that work is to define how to deliver se= rver-side (but, in the future, also client-side via EAP-CREDS :D) certifica= tes. We are also evaluating the deployment of the same (or very similar) approac= h for the DOCSIS(r) standard (Cable Networks). I also want to point out that CMP is already used in 3gpp (the very basic v= ersion) in their SIM-based (only for an initial authentication) certificate= provisioning system (well, just the very basic of the protocol here). Last but not least, I do like CMP because it allows me to use it independen= tly from the transport protocol, which is a huge win for me (e.g., when gra= nting access to the network and connectivity is not there yet, I want to be= able to provision/manage the credentials even before the device goes onlin= e). Something like ACME, for example, it is completely useless for all my u= se-cases (and super inefficient :D). I will be happy to provide my input for the work, if needed :D Just my 2 cents... Cheers, Max On 5/8/19 9:02 AM, Brockhaus, Hendrik wrote: Hi Panos, missed you in Prague. Steffen had a discussion on the focus of our CMP profile with Jim after the= ACE meeting in Prague. May be we did not focus enough on industrial use ca= ses. Our focus in not in the first place on constrained devices, but we bel= ieve that CMP would also work perfectly on all those devices capable to run= TLS. Currently CMP is already used in mobile networks and in rail networks.. But= we see the need to specify the needed uses cases in more detail to get int= eroperable implementations. The big advantage of CMP for industrial use is that we do not have any secu= rity requirements to the transport of the messages, since CMP messages are = self-contained and support end-to-end security. A hop-by-hop security or a= synchronous transport is not always feasible. Hendrik Von: Panos Kampanakis (pkampana) Gesendet: Mittwoch, 8. Mai 2019 16:00 An: spasm@ietf.org; Russ Housley ; Brockhaus, Hendrik (CT RDA ITS SEA-DE) Cc: Jim Schaad ; Fri= es, Steffen (CT RDA ITS) Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Hendrik, Long time since we talked. With such a profile, I have a concern that what happened with SCEP, CMC, CM= Pv2, EST is likely to happen in constrained environments. Using two or more= protocols (EST-coaps, a CMP profile over different transports, and others)= that do similar things would lead to fragmentation and confuse vendors tha= t want to pick one. I am not sure I have heard a broad need for a CMP profile in ACE. If this i= s a single vendor need, does IETF even need to standardize this CMP profile= ? Panos From: Spasm > On Beha= lf Of Brockhaus, Hendrik Sent: Wednesday, May 08, 2019 5:10 AM To: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; ste= ffen.fries@siemens.com Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director [OpenCA Logo] --_000_AM0PR10MB240200E9F587DADDDE018ACCFE0F0AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

O= K, understood. Thank you for the clarification.

L= et us see what is finally needed for Max use cases.

S= ee an explanation on the needed CMP update inline.

 

Von:<= span style=3D"color:windowtext"> Panos Kampanakis (pkampana) <pkampana@c= isco.com>
Gesendet: Freitag, 10. Mai 2019 19:29
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@sie= mens.com>; Dr. Pala <director@openca.org>; spasm@ietf.org
Betreff: RE: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

> tailor the features of= CMP to the needed subset and specify this subset precisely to ease interop= erable implementations<= o:p>

&n= bsp;

You are= creating a profile for CMP with a subset of its feature and minor updates = to the protocol itself. I was not sure if the subset you need for industria= l automation will match exactly the simplified profile Max needs for the EAP-CREDS.

 

[Bro] As discussed wit= h Jim, the goal is to keep the very limited changes to CMP in a separate I-= D and do the tailoring in the profile document.

F= inally there is only one real change to better support ECC and post-quantum= algorithms in CMP.

-= -> Change EncryptedValue to EncryptedKey to also support EnvelopedData.<= o:p>

A= s EncryptedKey is a choice of EncryptedValue and EnvelopedData this change = should be backward compatible. Therefore I do not see much problems there.<= o:p>

Ever= ything else are more clarification topics that are of general value for CMP= from my point of view. This is why I would suggest to put them into the CM= P updates document, but they could also be shifted to the CMP profile. This can be discussed and decides in the WG= then.

&n= bsp;

&n= bsp;

F= rom: Spasm <<= a href=3D"mailto:spasm-bounces@ietf.org">spasm-bounces@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Friday, May 10, 2019 3:11 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com>; Dr. Pala <director@openca.org>; spasm@ietf.org
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Panos=

 

I am= not sure if I got your point right. Can you explain the difference you mak= e between ‘Hendrik’s profile’ and ‘CMP native’= ;.

 

Rega= rdless of the very limited changes to be covered in a CMP updates I-D, the = goal of our profile is not to change CMP but to ease its use. Therefore I w= ould say that our profile also uses CMP native.

If M= ax has further certificate management uses cases, not yet covered in the pr= ofile, I am happy to specify those together with him making use of the exis= ting CMP mechanisms.

The = purpose of the CMP profile is to tailor the features of CMP to the needed s= ubset and specify this subset precisely to ease interoperable implementatio= ns.

 

Hend= rik

 

Von:<= span style=3D"color:windowtext"> Spasm <spasm-bounces@ietf.org> Im Auftrag von Panos Kampanakis (pkampana)
Gesendet: Donnerstag, 9. Mai 2019 20:56
An: Dr. Pala <director@ope= nca.org>; spasm@ietf.org
Betreff: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Max,=

&n= bsp;

> Fi= rst of all, this work is something I needed to do for the EAP-CREDS (Creden= tials Management over EAP) work (we need a simplified profile for the EAP-C= REDS to work :D).

&n= bsp;

Is this= the same profile proposed in Hendrik’s draft or a different one?

&n= bsp;

I don&#= 8217;t question that CMP has it uses, but are the rest of the usecases you = listed out interested in using Hendrik’s profile or are they just int= erested in CMP native?


Rgs,

Panos <= o:p>

&n= bsp;

F= rom: Spasm <<= a href=3D"mailto:spasm-bounces@ietf.org">spasm-bounces@ietf.org> On Behalf Of Dr. Pala
Sent: Wednesday, May 08, 2019 7:12 PM
To: spasm@ietf.org
Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and= lightweight profile (RE: Follow-up on lightweight CMP profile)<= /span>

 

Hi Hendrik, all,

I too support this effort and I have few use-cases = that might be relevant.

First of all, this work is something I needed to do= for the EAP-CREDS (Credentials Management over EAP) work (we need a simpli= fied profile for the EAP-CREDS to work :D).

Another important use case we have is related to me= dical devices (we have been working with CMI for a while now): in that envi= ronment we need to use reasonably-lived certificates (not the usual 20yrs d= evice cert) with frequent renewals: when trying to select a simple protocol, CMP seemed the right choice over = others because of its ease of implementation and flexibility.

Another use-case is within Wireless Broadband Allia= nce (WBA) - there, we are working to define and deploy a RadSec-only deploy= ment for a WBA-centric roaming infrastructure, and part of that work is to = define how to deliver server-side (but, in the future, also client-side via EAP-CREDS :D) certificates.=

We are also evaluating the deployment of the same (= or very similar) approach for the DOCSIS(r) standard (Cable Networks).=

I also want to point out that CMP is already used i= n 3gpp (the very basic version) in their SIM-based (only for an initial aut= hentication) certificate provisioning system (well, just the very basic of = the protocol here).

Last but not least, I do like CMP because it allows= me to use it independently from the transport protocol, which is a huge wi= n for me (e.g., when granting access to the network and connectivity is not= there yet, I want to be able to provision/manage the credentials even before the device goes online). Something like ACME, = for example, it is completely useless for all my use-cases (and super ineff= icient :D).

I will be happy to provide my input for the work, i= f needed :D

Just my 2 cents...

Cheers,
Max

 

On 5/8/19 9:02 AM, Brockhaus, H= endrik wrote:

Hi Panos,

 

missed you in Prague.

 

Steffen had a discussion on the= focus of our CMP profile with Jim after the ACE meeting in Prague. May be = we did not focus enough on industrial use cases. Our focus in not in the fi= rst place on constrained devices, but we believe that CMP would also work perfectly on all those devices capable= to run TLS.

Currently CMP is already used i= n mobile networks and in rail networks.. But we see the need to specify the= needed uses cases in more detail to get interoperable implementations.

The big advantage of CMP for in= dustrial use is that we do not have any security requirements to the transp= ort of the messages, since CMP messages are self-contained and support end-= to-end security.  A hop-by-hop security or asynchronous transport is not always feasible.

 

Hendrik

 

Von: Panos Kampanakis (pkampana) <pkampana@cisco.com>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: Jim Schaad <ietf@au= gustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com&= gt;
Betreff: RE: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

 <= /span>

Hi Hend= rik,

 <= /span>

Long ti= me since we talked.

 <= /span>

With su= ch a profile, I have a concern that what happened with SCEP, CMC, CMPv2, ES= T is likely to happen in constrained environments. Using two or more protoc= ols (EST-coaps, a CMP profile over different transports, and others) that do similar things would lead to fragmentation= and confuse vendors that want to pick one.

 <= /span>

I am no= t sure I have heard a broad need for a CMP profile in ACE. If this is a sin= gle vendor need, does IETF even need to standardize this CMP profile?

 <= /span>

Panos

 <= /span>

 <= /span>

From: Spasm <spasm-bounc= es@ietf.org> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; steffen.fries@siemens.com<= br> Subject: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, all,=

 

as discussed at IETF104 and on = this list we would like to spend further work on updating and profiling CMP= focusing on industrial use cases.

To get input, feedback and supp= ort from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@v= igilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about= two weeks away.  You would need to propose text for the charter on th= is list, and see if there are people that will review and implement.

 

Russ

 

=  

On May 3, 2019, at 4:52 AM, Bro= ckhaus, Hendrik <hendri= k.brockhaus@siemens.com> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ....

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

___________________________________= ____________
Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailman/listinfo/spasm

 

=  

_______________________________________________
Spasm mailing list
Spasm@ietf.org
https://w=
ww.ietf.org/mailman/listinfo/spasm

--

Best Regards,

Massimiliano Pala, Ph.D.
OpenCA Labs Director

3D"OpenCA

--_000_AM0PR10MB240200E9F587DADDDE018ACCFE0F0AM0PR10MB2402EURP_-- --_004_AM0PR10MB240200E9F587DADDDE018ACCFE0F0AM0PR10MB2402EURP_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3146; creation-date="Mon, 13 May 2019 06:30:49 GMT"; modification-date="Mon, 13 May 2019 06:30:49 GMT" Content-ID: Content-Transfer-Encoding: base64 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= --_004_AM0PR10MB240200E9F587DADDDE018ACCFE0F0AM0PR10MB2402EURP_-- From nobody Wed May 15 06:51:52 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22FDB120167; Wed, 15 May 2019 06:51:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Peter Yee via Datatracker To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc6844bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Peter Yee Message-ID: <155792831007.17593.15497489606283752991@ietfa.amsl.com> Date: Wed, 15 May 2019 06:51:50 -0700 Archived-At: Subject: [lamps] Genart last call review of draft-ietf-lamps-rfc6844bis-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 13:51:50 -0000 Reviewer: Peter Yee Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-lamps-rfc6844bis-06 Reviewer: Peter Yee Review Date: 2019-05-15 IETF LC End Date: 2019-05-08 IESG Telechat date: Not scheduled for a telechat Summary: Ready with Issues. This draft is an update to RFC 6844 dealing with the CAA RR used to notify CAs as to which CA(s) are allowed to issue certificates for a particular domain. The issues and nits I note are rather minor. Apologies for the lateness of this review. Major issues: Minor issues: Page 10, 2nd paragraph: the appearance of "sub.wild.example.com" presupposes that there was no other RRset that matched sub.wild.example.com (or a "deeper" domain name) already. That assumption should be noted in this paragraph. Page 13, section 5.6: a little context should be given here. This abuse is only plausible if the domain owner is being given the RRset data by the CA rather than generating that data itself. Nits/editorial comments: Page 5, 1st partial paragraph: change "with" to "within". Page 5, 1st full paragraph: regarding the reference to Section 4, shouldn't this actually be Section 3? Page 8, definition of "Value", 2nd sentence: delete redundant "the". Page 15, 1st partial paragraph, 1st partial sentence: change "use" to "used". Page 15, section 7, 2nd paragraph: is there a reference available for the term "WebPKI"? Page 15, section 7, 3rd paragraph, 1st sentence: insert "the" before "issue". From nobody Thu May 16 05:21:17 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8AC12009C; Thu, 16 May 2019 05:21:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155800926960.19686.5590486837228999154.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2019 05:21:09 -0700 Archived-At: Subject: [lamps] Magnus Westerlund's No Objection on charter-ietf-lamps-03-01: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 12:21:10 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-lamps-03-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-lamps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some updated milestone dates would not hurt. From nobody Thu May 16 06:33:13 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88682120045; Thu, 16 May 2019 06:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhFnJ3hZDWzO; Thu, 16 May 2019 06:33:11 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CAB9120025; Thu, 16 May 2019 06:33:11 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4GDX7DM008349; Thu, 16 May 2019 09:33:07 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x4GDX7DM008349 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1558013588; bh=/l9cnSNcNGFkzgzJW4DIeW//z5PPdnZXWnG0OlcxlBQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=trHP5jiTzpUVRjlJmaQ892rwse17jb2+/pJ1OYQA+ZGnYUr5d7bTrsonn0XxRjDBV YQtLh2lFYCe0sssdEEZW29zmsEfGKMENdUKz/sFdxmCWQ/IlLHzxfPPXPP6naLMRWe f6KRSFyAGMXQ5NoBietOxT9Lkw3wYGfdYyrNHbPA= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4GDX47j001807; Thu, 16 May 2019 09:33:04 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Thu, 16 May 2019 09:33:04 -0400 From: Roman Danyliw To: Magnus Westerlund CC: "spasm@ietf.org" , "lamps-chairs@ietf.org" , The IESG Thread-Topic: [lamps] Magnus Westerlund's No Objection on charter-ietf-lamps-03-01: (with COMMENT) Thread-Index: AQHVC+HcgCNL3rA3+UWJL9IBz3FzYKZtv9sQ Date: Thu, 16 May 2019 13:33:04 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3367E32@marathon> References: <155800926960.19686.5590486837228999154.idtracker@ietfa.amsl.com> In-Reply-To: <155800926960.19686.5590486837228999154.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Magnus Westerlund's No Objection on charter-ietf-lamps-03-01: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 13:33:12 -0000 > -----Original Message----- > From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Magnus > Westerlund via Datatracker > Sent: Thursday, May 16, 2019 8:21 AM > To: The IESG > Cc: spasm@ietf.org; lamps-chairs@ietf.org > Subject: [lamps] Magnus Westerlund's No Objection on charter-ietf-lamps- > 03-01: (with COMMENT) >=20 > Magnus Westerlund has entered the following ballot position for > charter-ietf-lamps-03-01: No Objection >=20 > When responding, please keep the subject line intact and reply to all ema= il > addresses included in the To and CC lines. (Feel free to cut this introdu= ctory > paragraph, however.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-lamps/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Some updated milestone dates would not hurt. That makes sense. I'll look to the chairs to help get those updated. Roman From nobody Thu May 16 06:42:22 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED121120094; Thu, 16 May 2019 06:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqVyIyip1pMw; Thu, 16 May 2019 06:42:19 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344BF120044; Thu, 16 May 2019 06:42:19 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4GDgHhn009576; Thu, 16 May 2019 09:42:17 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x4GDgHhn009576 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1558014137; bh=3TpN6yWyQzuKUKNDj6UBCysZkNRhT/xVtmlIqU5WWf4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MG0ul2tuPqR6HuuzhIMC7NwzTbYIuuvg5XIuwgOhnTdxkWM/DmaolymWvQzdOTy6j CRae0XuH5G/E1jmiRhnWCOHlEQHGw7brTut1Rm1h0PCOG45W8CVTYbvb1ZP4STd6SM I4y0Obg+NUWF2kirCbWF8m1NZIdfUR7lduy1krOs= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4GDg7ao003929; Thu, 16 May 2019 09:42:07 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Thu, 16 May 2019 09:42:06 -0400 From: Roman Danyliw To: Barry Leiba , The IESG CC: "spasm@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) Thread-Index: AQHVCDu/dLmgFntge0mRMiKuYClIdKZtx3PA Date: Thu, 16 May 2019 13:42:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3367E74@marathon> References: <155760806741.23982.17913134945724564971.idtracker@ietfa.amsl.com> In-Reply-To: <155760806741.23982.17913134945724564971.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 13:42:21 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3Bhc20gW21haWx0bzpz cGFzbS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQmFycnkgTGVpYmEgdmlhDQo+IERh dGF0cmFja2VyDQo+IFNlbnQ6IFNhdHVyZGF5LCBNYXkgMTEsIDIwMTkgNDo1NCBQTQ0KPiBUbzog VGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+IENjOiBzcGFzbUBpZXRmLm9yZzsgbGFtcHMtY2hh aXJzQGlldGYub3JnDQo+IFN1YmplY3Q6IFtsYW1wc10gQmFycnkgTGVpYmEncyBObyBPYmplY3Rp b24gb24gY2hhcnRlci1pZXRmLWxhbXBzLTAzLTAxOg0KPiAod2l0aCBDT01NRU5UKQ0KPiANCj4g QmFycnkgTGVpYmEgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9y DQo+IGNoYXJ0ZXItaWV0Zi1sYW1wcy0wMy0wMTogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJl c3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0 byBhbGwgZW1haWwNCj4gYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMu IChGZWVsIGZyZWUgdG8gY3V0IHRoaXMgaW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZl ci4pDQo+IA0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3Qg cG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvY2hhcnRlci1pZXRmLWxhbXBzLw0KPiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+IE5vIG9iamVjdGlvbiB0byB0aGUg bGlzdCBvZiB3b3JrIGl0ZW1zLCBidXQgbWF5YmUgaXTigJlzIHRpbWUgdG8gcmVuYW1lIHRoaXMN Cj4g4oCcQU1QU+KAnSwgYXMg4oCcTOKAnSBkb2VzbuKAmXQgc2VlbSB0byBhcHBseSBhbnkgbW9y ZS4NCg0KVGhpcyBvcGVucyB1cCBhIGRlYmF0ZSBvbiB0aGUgc2VtYW50aWNzIG9mICJsaW1pdGVk Ii4gIEknbSBub3Qgc3VyZSBpdCdzIHdvcnRoIHRoZSBlZmZvcnQuDQoNClJvbWFuDQo= From nobody Thu May 16 06:44:58 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C751200A4 for ; Thu, 16 May 2019 06:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOa_NexVoSEN for ; Thu, 16 May 2019 06:44:47 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6BE120094 for ; Thu, 16 May 2019 06:44:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C4232300AE3 for ; Thu, 16 May 2019 09:25:29 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rxlS75ZJ7-Y1 for ; Thu, 16 May 2019 09:25:28 -0400 (EDT) Received: from [192.168.58.240] (unknown [94.107.234.206]) by mail.smeinc.net (Postfix) with ESMTPSA id 62D783001F1; Thu, 16 May 2019 09:25:27 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Russ Housley In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3367E74@marathon> Date: Thu, 16 May 2019 09:44:43 -0400 Cc: Barry Leiba , IESG , "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <155760806741.23982.17913134945724564971.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3367E74@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 13:44:50 -0000 > On May 16, 2019, at 9:42 AM, Roman Danyliw wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Barry Leiba = via >> Datatracker >> Sent: Saturday, May 11, 2019 4:54 PM >> To: The IESG >> Cc: spasm@ietf.org; lamps-chairs@ietf.org >> Subject: [lamps] Barry Leiba's No Objection on = charter-ietf-lamps-03-01: >> (with COMMENT) >>=20 >> Barry Leiba has entered the following ballot position for >> charter-ietf-lamps-03-01: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-lamps/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> No objection to the list of work items, but maybe it=E2=80=99s time = to rename this >> =E2=80=9CAMPS=E2=80=9D, as =E2=80=9CL=E2=80=9D doesn=E2=80=99t seem = to apply any more. >=20 > This opens up a debate on the semantics of "limited". I'm not sure = it's worth the effort. Another name change would not be helpful. The mail list still has the = original name... Russ From nobody Thu May 16 07:11:08 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1AC1200BA; Thu, 16 May 2019 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 szFd_xevLnmm; Thu, 16 May 2019 07:11:05 -0700 (PDT) Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (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 E16F5120098; Thu, 16 May 2019 07:11:04 -0700 (PDT) Received: by mail-io1-f54.google.com with SMTP id g84so2713209ioa.1; Thu, 16 May 2019 07:11:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cFGc7zl7v1fk1rOKSUOzpwpEZldUYR0YL0eTEq3kM64=; b=TmIHc676/iBOWMMmoDejAAhvE4wkxddc2m+OzcO+pLdgF1brxo22O65qPSmXFJZNAF 7UDdgifxqaAHdgikeF19CQPcEcxFrv5XZn2afjmXVz50TSFd15uB3843nGsRLjH/GiYC Cl7jCZmRlrh1zEev/2W/V4Ia/NB2Q8ICDD6tFAiWCvuddvoI7uVxgJ1D880qXawzNN3W zmGhd8dPgfL69xgWpFsTi5z/cZ+H1JZ74pW92bmXxrEHlUXazFXfyu3KlFyfbc9UAmcY p8DQH0fRsu39SkLvld2/n995PrzwlCvU7qparCoTbDc5LqQfg46wOoAQ4k9ZMBL2hw2F N9sQ== X-Gm-Message-State: APjAAAXWokeJM7CYtrQQAyWvzQmNvWkcqdvA25h5q34C14KVAZvDQJeI ZSh5z7fBlxtsDNouEB0431iKB5ij07KXqGEklnU= X-Google-Smtp-Source: APXvYqxngCdBJoRiuRfdmwO4nIqgdSxs8ezHC5fu7/kjVZM+Ocd30y0Cb22CbAj5wxhfMij5GP+ugOuvGT9NQDDvbdQ= X-Received: by 2002:a5d:8357:: with SMTP id q23mr28035516ior.10.1558015864004; Thu, 16 May 2019 07:11:04 -0700 (PDT) MIME-Version: 1.0 References: <155760806741.23982.17913134945724564971.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3367E74@marathon> In-Reply-To: From: Barry Leiba Date: Thu, 16 May 2019 10:10:53 -0400 Message-ID: To: Russ Housley Cc: "Roman D. Danyliw" , IESG , "spasm@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 14:11:07 -0000 It wasn't a serious comment, really... b On Thu, May 16, 2019 at 9:45 AM Russ Housley wrote: > > > > > On May 16, 2019, at 9:42 AM, Roman Danyliw wrote: > > > > > > > >> -----Original Message----- > >> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Barry Leiba v= ia > >> Datatracker > >> Sent: Saturday, May 11, 2019 4:54 PM > >> To: The IESG > >> Cc: spasm@ietf.org; lamps-chairs@ietf.org > >> Subject: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-0= 1: > >> (with COMMENT) > >> > >> Barry Leiba has entered the following ballot position for > >> charter-ietf-lamps-03-01: No Objection > >> > >> When responding, please keep the subject line intact and reply to all = email > >> addresses included in the To and CC lines. (Feel free to cut this intr= oductory > >> paragraph, however.) > >> > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/charter-ietf-lamps/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> No objection to the list of work items, but maybe it=E2=80=99s time to= rename this > >> =E2=80=9CAMPS=E2=80=9D, as =E2=80=9CL=E2=80=9D doesn=E2=80=99t seem to= apply any more. > > > > This opens up a debate on the semantics of "limited". I'm not sure it'= s worth the effort. > > Another name change would not be helpful. The mail list still has the or= iginal name... > > Russ > From nobody Thu May 16 09:04:14 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE33120320; Thu, 16 May 2019 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Se9GO9wXEmqe; Thu, 16 May 2019 09:04:02 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7492F12031A; Thu, 16 May 2019 09:04:02 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x4GG2Q8h012948; Thu, 16 May 2019 17:03:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Or6hTCNpEsZ8+gzIWER9Bw2Qaw2g1a1+iSj0uCuDrMA=; b=gweG3toc/mD4W7FQ7gz5DMbO8ZbgDcMkpZV8V5Up+jETccVgOk0uqmBmrlhXS8PXvGQz MxEqipGUcjZcIuJv66b+YT10cOzNY2wRaIcLhzDmIvLPRjKRdLK+0zq9uZKSeDKghAsw kvsxWQ6GMZKrlBX93GNhfs+4PHW0d3gHNhpUylYwp/0FMclHERmHKCghFMIucmFKTCJa uAR2ohckBMD592Bw5en0am2ai6SmU5hnWLyrrW3eHSKLfcv/AkE3mbb4OO6YK7oC8H+X NmUxooq8/IDowmK5TBBbDtlwgMNc2gm+JYzeFHqtKqBBLeuykQuWZk/zGhv5IP0W9VUW Yg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2sgsy2jxmm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 May 2019 17:03:58 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x4GFlHFU008073; Thu, 16 May 2019 12:03:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.21]) by prod-mail-ppoint2.akamai.com with ESMTP id 2sdsqwus93-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 16 May 2019 12:03:57 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 16 May 2019 11:03:27 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1473.003; Thu, 16 May 2019 11:03:27 -0500 From: "Salz, Rich" To: Roman Danyliw , Barry Leiba , "The IESG" CC: "spasm@ietf.org" , "lamps-chairs@ietf.org" Thread-Topic: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) Thread-Index: AQHVCDu93MyISf8ZRU6QazwBcINTXqZuHaaA///kcAA= Date: Thu, 16 May 2019 16:03:26 +0000 Message-ID: References: <155760806741.23982.17913134945724564971.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3367E74@marathon> In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B3367E74@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.19.0.190512 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.219] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-16_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=580 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160100 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=590 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905160102 Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 16:04:12 -0000 PiAgICBUaGlzIG9wZW5zIHVwIGEgZGViYXRlIG9uIHRoZSBzZW1hbnRpY3Mgb2YgImxpbWl0ZWQi LiAgSSdtIG5vdCBzdXJlIGl0J3Mgd29ydGggdGhlIGVmZm9ydC4NCiAgDQpFc3BlY2lhbGx5IHNp bmNlIHdlIHNlZW0gdW5hYmxlIHRvIGNoYW5nZSB0aGUgbWFpbGluZyBsaXN0IG5hbWUuICA6KA0K DQo= From nobody Thu May 16 16:30:26 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 885EE1200BA; Thu, 16 May 2019 16:30:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tim Hollebeek via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, lamps-chairs@ietf.org, Tim Hollebeek , iesg-secretary@ietf.org, tim.hollebeek@digicert.com Message-ID: <155804942454.19586.10040242095963451582.idtracker@ietfa.amsl.com> Date: Thu, 16 May 2019 16:30:24 -0700 Archived-At: Subject: [lamps] Publication has been requested for draft-ietf-lamps-cms-mix-with-psk-04 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2019 23:30:25 -0000 Tim Hollebeek has requested publication of draft-ietf-lamps-cms-mix-with-psk-04 as Proposed Standard on behalf of the LAMPS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ From nobody Thu May 16 18:48:41 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41F512033B for ; Thu, 16 May 2019 18:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=JRhXwFNf; dkim=pass (1024-bit key) header.d=digicert.com header.b=tghDIbin 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 Psq0PZ3CnF30 for ; Thu, 16 May 2019 18:48:35 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EE20120340 for ; Thu, 16 May 2019 18:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1558057713; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:openpgp:autocrypt; bh=AGxjv45usq4wOKRMmukTlcWJZ5KRV9sr4REWvjX7bEY=; b=JRhXwFNfsRKJwATuOfszDvDzzc0XLglxJSrLMrbOTPaCRcDjmyzZAYUNvjEtnffqNZyaCA GPxMTvdRGa57iDywMlizC7E69Gh8Op2926byHVCFFEJmkksTbfO5B5IgHM9X2p1WvOr17Z SOgKOwdVfqFCMdhrBmQ6i6KhpZf0tko= Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01lp2050.outbound.protection.outlook.com [104.47.34.50]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-99-3PZVJnq3MECskpRlPI-E_Q-1; Thu, 16 May 2019 21:48:31 -0400 X-MC-Unique: 3PZVJnq3MECskpRlPI-E_Q-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AGxjv45usq4wOKRMmukTlcWJZ5KRV9sr4REWvjX7bEY=; b=tghDIbing2RNYJycVTgAjGsEPMuMi03WRoCc8TDsW91qr2LjHRsifu2V2Z88BGPBqZDaWl0sufG0l4zP0ybzvX3zJ3d8X/Dx6otvSmn31Zu71zw7QlQP1392DS+6JpWWk0rMXb9dAk3PUDVty7r9bjMBhLLz+WVyMOnvtxTdNRs= Received: from MWHPR14MB1533.namprd14.prod.outlook.com (10.173.233.145) by MWHPR14MB1661.namprd14.prod.outlook.com (10.171.146.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.16; Fri, 17 May 2019 01:48:28 +0000 Received: from MWHPR14MB1533.namprd14.prod.outlook.com ([fe80::b9aa:dc2e:2670:8d4f]) by MWHPR14MB1533.namprd14.prod.outlook.com ([fe80::b9aa:dc2e:2670:8d4f%7]) with mapi id 15.20.1900.010; Fri, 17 May 2019 01:48:28 +0000 From: Tim Hollebeek To: Russ Housley , "Roman D. Danyliw" CC: "spasm@ietf.org" , Barry Leiba , IESG Thread-Topic: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) Thread-Index: AQHVCDu9VG+xqoJvZ0aka+CGnBny8KZtydSAgAAAvICAAMnUkA== Date: Fri, 17 May 2019 01:48:28 +0000 Message-ID: References: <155760806741.23982.17913134945724564971.idtracker@ietfa.amsl.com> <359EC4B99E040048A7131E0F4E113AFC01B3367E74@marathon> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [113.29.9.238] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5e99f95-e6df-4645-bb98-08d6da69c245 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(49563074)(7193020); SRVR:MWHPR14MB1661; x-ms-traffictypediagnostic: MWHPR14MB1661: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(136003)(346002)(376002)(199004)(189003)(66066001)(54906003)(110136005)(99936001)(2906002)(102836004)(305945005)(55236004)(6506007)(7736002)(6246003)(316002)(71200400001)(4326008)(71190400001)(25786009)(53936002)(256004)(33656002)(14454004)(73956011)(11346002)(446003)(486006)(478600001)(44832011)(476003)(6436002)(229853002)(64756008)(66556008)(66446008)(66476007)(55016002)(9686003)(66616009)(76116006)(66946007)(86362001)(7696005)(99286004)(76176011)(8936002)(81166006)(81156014)(8676002)(68736007)(74316002)(6116002)(5660300002)(558084003)(26005)(186003)(52536014)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1661; H:MWHPR14MB1533.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kDsPE26lpgDQ/3URS4B+lZRxkP7zuAaHZD+nO8AxSlXPQSRElSiiU0fd/jkTZBICaPSiBXzZk2cvZEWeOuFrWcANtKYCazyt8+gea2THqcmRlwSGv3x8EmaLBf1+ZAk2+u/UANQLstCoN+0BIm8GiumvXvxvgAbxN4+uaRPiszlPaMZHln8EZe53n9+CfeYvVgtWHGeNz/mvfgR9v+Np5CmzmjmkIKhiSy0+Eva5txe/i9IFIhe8T6WEqu6kwHSderKjg+92vcqpActm6jTe2iB7Su2qZCbEvlvPdal95WtzJeyHIVIlyTVkntnFa19w7FmcSMDaLBquGMvXOwEro1yZ1saDkckgzanbQ+6+/TqDUI+8httW1e5lswpNtiUtuDin/uXaop2orz4EqxPB0YpDS3btnXNEcMp9Lxtg9t0= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_01D4_01D50C9E.00B22A60" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5e99f95-e6df-4645-bb98-08d6da69c245 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2019 01:48:28.3843 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1661 Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on charter-ietf-lamps-03-01: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 01:48:40 -0000 ------=_NextPart_000_01D4_01D50C9E.00B22A60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > Another name change would not be helpful. The mail list still has the > original name... There's one name change that would be helpful. Changing the name back to SPASM ... mail list name problem fixed. -Tim ------=_NextPart_000_01D4_01D50C9E.00B22A60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwNTE3MDE0ODAzWjAvBgkqhkiG9w0BCQQxIgQgDakvJdEJQEahl8LcWVHjpIWNtwub sRYEpR/pLyZbpRcwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAHYLtVe7bndMDDKhT52f7QCcnf2z0nRcu5mqheirVafzknbVPIpdB3Fqr3epvNCnMmATlfth OKI+oF5cT3k8BBCh6UtwrepO+KEwgLAzuaScX9GP1umTBngxKkSwWmGjanIRWIV5FkmpUdDvXFrB mu7TtkxBgWRyeYmDwrFQcdujuziJlZjlxpxbBlI4lraLaa/7I/4aQSuiRSIQ4tUidnU6by2e7v+7 C3Umh6zH/stAFoqM4cFh3l970A9m8m9+YBDMt+xcDMsDLw1NgzwZexltTt6fU2ZuSQvhyPW3RF/I SZsb0S0oCX55C+YhRLujh4eeYOeJNMhYk94MTyJCLWkAAAAAAAA= ------=_NextPart_000_01D4_01D50C9E.00B22A60-- From nobody Fri May 17 10:53:30 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F008120256; Fri, 17 May 2019 10:53:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Cc: spasm@ietf.org, lamps-chairs@ietf.org, The IESG Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155811559344.26459.2925899045093783563.idtracker@ietfa.amsl.com> Date: Fri, 17 May 2019 10:53:13 -0700 Archived-At: Subject: [lamps] WG Action: Rechartered Limited Additional Mechanisms for PKIX and SMIME (lamps) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2019 17:53:14 -0000 The Limited Additional Mechanisms for PKIX and SMIME (lamps) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Limited Additional Mechanisms for PKIX and SMIME (lamps) ----------------------------------------------------------------------- Current status: Active WG Chairs: Russ Housley Tim Hollebeek Assigned Area Director: Roman Danyliw Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: spasm@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/spasm Archive: https://mailarchive.ietf.org/arch/browse/spasm/ Group page: https://datatracker.ietf.org/group/lamps/ Charter: https://datatracker.ietf.org/doc/charter-ietf-lamps/ The PKIX and S/MIME Working Groups have been closed for some time. Some updates have been proposed to the X.509 certificate documents produced by the PKIX Working Group and the electronic mail security documents produced by the S/MIME Working Group. The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working Group is chartered to make updates where there is a known constituency interested in real deployment and there is at least one sufficiently well specified approach to the update so that the working group can sensibly evaluate whether to adopt a proposal. The LAMPS WG is now tackling these topics: 1. Specify a discovery mechanism for CAA records to replace the one described in RFC 6844. Implementation experience has demonstrated an ambiguity in the handling of CNAME and DNAME records during discovery in RFC 6844, and subsequent discussion has suggested that a different discovery approach would resolve limitations inherent in the approach used in RFC 6844. 2. Specify the use of SHAKE128/256 and SHAKE256/512 for PKIX and S/MIME. Unlike the previous hashing standards, the SHA-3 family of functions are the outcome of an open competition. They have a clear design rationale and have received a lot of public analysis, giving great confidence that the SHA-3 family of functions are secure. Also, since SHA-3 uses a very different construction from SHA-2, the SHA-3 family of functions offers an excellent alternative. In particular, SHAKE128/256 and SHAKE256/512 offer security and performance benefits. 3. Specify the use of short-lived X.509 certificates for which no revocation information is made available by the Certification Authority. Short-lived certificates have a lifespan that is shorter than the time needed to detect, report, and distribute revocation information. As a result, revoking short-lived certificates is unnecessary and pointless. 4. Specify the use of a pre-shared key (PSK) along with other key management techniques with supported by the Cryptographic Message Syntax (CMS) as a mechanism to protect present day communication from the future invention of a large-scale quantum computer. The invention of a large-scale quantum computer poses a serious challenge for the key management algorithms that are widely deployed today, especially the key transport and key agreement algorithms used today with the CMS to protect S/MIME messages. 5. Specify the use of hash-based signatures with the Cryptographic Message Syntax (CMS). Hash-based signature use small private and public keys, and they have low computational cost; however, the signature values are quite large. For this reason they might not be used for signing X.509 certificates or S/MIME messages; however, since hash-based signature algorithms are secure even if a large-scale quantum computer is invented. The low computational cost for signature verification makes hash-based signatures attractive in the Internt of Things environments, and the quantum resistance makes them attractive for the distribution of software updates. 6. Specify a certificate extension that is carried in a self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor. 7. Update the specification for the cryptographic protection of email headers -- both for signatures and encryption -- to improve the implementation situation with respect to privacy, security, usability and interoperability in cryptographically-protected electronic mail. Most current implementations of cryptographically-protected electronic mail protect only the body of the message, which leaves significant room for attacks against otherwise-protected messages. In addition, the LAMPS WG may investigate other updates to documents produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt any of these potential work items without rechartering. Milestones: Jun 2018 - Adopt a draft for short-lived certificate conventions Jun 2018 - Adopt a draft for the CMS with PSK Jun 2018 - Adopt a draft for hash-based signatures with the CMS Jun 2018 - Adopt a draft for root key rollover certificate extension Jul 2018 - rfc6844bis sent to IESG for standards track publication Aug 2018 - Root key rollover certificate extension sent to IESG for informational publication Sep 2018 - SHAKE128/256 and SHAKE256/512 for PKIX sent to IESG for standards track publication Sep 2018 - SHAKE128/256 and SHAKE256/512 for S/MIME sent to IESG for standards track publication Oct 2018 - Short-lived certificate conventions sent to IESG for BCP publication Oct 2018 - The CMS with PSK sent to IESG for standards track publication Dec 2018 - Hash-based signatures with the CMS sent to IESG for standards track publication From nobody Mon May 20 06:42:58 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1EB1200A1 for ; Mon, 20 May 2019 06:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1blHxynE9Abq for ; Mon, 20 May 2019 06:42:53 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20075.outbound.protection.outlook.com [40.107.2.75]) (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 D517B1201A0 for ; Mon, 20 May 2019 06:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gwha/lrkDBZvbatLkVXqDB418sD0G1+jDBRZUu2wlFc=; b=SiaED/9jofE53ntjkHqYefavB4hPplIKi5P1s0tHsNfwYwlSn5/+OF1GzTcJqA8ueF4hyVi5cwPZYY43HsjLt+GtI3sY3w3goIDy4Xw+Nt5o/AW9v4Gudl79yRwEUgt1xWcMCDP/RoR/pwlft+D1heMvQlSXeTatYmlohyLTojE= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2130.EURPRD10.PROD.OUTLOOK.COM (20.177.108.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1900.18; Mon, 20 May 2019 13:42:48 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1900.020; Mon, 20 May 2019 13:42:48 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: "steffen.fries@siemens.com" , "spasm@ietf.org" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQJlFWLw Date: Mon, 20 May 2019 13:42:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca9e3887-e47e-4ea6-d711-08d6dd290bea x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2130; x-ms-traffictypediagnostic: AM0PR10MB2130: x-ms-exchange-purlcount: 1 x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(396003)(39860400002)(136003)(53754006)(199004)(189003)(256004)(14444005)(7110500001)(73956011)(102836004)(76116006)(2906002)(33656002)(76176011)(86362001)(7696005)(966005)(71190400001)(71200400001)(19627235002)(66476007)(66446008)(64756008)(66556008)(54906003)(66946007)(561944003)(53936002)(52536014)(9686003)(316002)(6306002)(2420400007)(26005)(8936002)(15650500001)(54896002)(74316002)(6916009)(446003)(7736002)(5660300002)(11346002)(6436002)(68736007)(66066001)(476003)(236005)(14454004)(53546011)(606006)(25786009)(6506007)(478600001)(99286004)(790700001)(6116002)(3846002)(55016002)(486006)(4326008)(186003)(8676002)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2130; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 1Fo1ehyg/9YxqNG34Pi6RBreJnzih+rtY1b43RZbV55+hHjlU7jCQXpPv5tyGhPoPF56kFiXipcZQY/VLN1nbRz0Yjgs2jhVP72HDB7q1wNv/0Yua/tDAx9gZCPKW4iD0w6Z8LezKZg1WBHEPyZO447itPe+smJdmpb7rgh3ypM6ZlhBqTu8XW+DbU+S89HM3VeQgwPAaaI0oViiszAcKk4/r1pIusnu7StEGsAZ7+9TQj1MuGnStL+coDbRuXuEJ7I2auJznKAZz9ddvWHeUjVtRYyZNRSXMsvt7xZTU1J385apFurmM+uvKk8MWSN8OcAYFiWSuFe/ziJ+VlosBd6b93ctNtHEd/KWSl1z77x8cPWf+1pIdRaUHpAotfwJ/qFrmD8GOMIE1dV8UdzKSfVw0GymMz0NYxW+FdKE8wA= Content-Type: multipart/alternative; boundary="_000_AM0PR10MB2402B5BB06E4FB59A8ECB16BFE060AM0PR10MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca9e3887-e47e-4ea6-d711-08d6dd290bea X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2019 13:42:48.1392 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2130 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 13:42:57 -0000 --_000_AM0PR10MB2402B5BB06E4FB59A8ECB16BFE060AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ We discussed my proposal on the mailing list. I feel there is quite some su= pport. Tomas, Max and Martin supported the activity. There were some questions and= concerns from Panos, that I hopefully could clarify. What is the next step? Hendrik Von: Spasm Im Auftrag von [ext] Brockhaus, Hendrik Gesendet: Mittwoch, 8. Mai 2019 11:10 An: spasm@ietf.org; Russ Housley Cc: Jim Schaad ; Fries, Steffen (CT RDA ITS) Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_AM0PR10MB2402B5BB06E4FB59A8ECB16BFE060AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ

&nbs= p;

We discussed my proposal on the mailing list. I feel there is quite s= ome support.

Tomas, Max and Martin supported the activity. There were some questio= ns and concerns from Panos, that I hopefully could clarify.

 

What is the next step?

 

Hendrik

 

Von: Spasm <spasm-bounces@ietf.org> = Im Auftrag von [ext] Brockhaus, Hendrik
Gesendet: Mittwoch, 8. Mai 2019 11:10
An: spasm@ietf.org; Russ Housley <housley@vigilsec.com>
Cc: Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RD= A ITS) <steffen.fries@siemens.com>
Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, = all,

&nbs= p;

as discussed at IETF104 and on this list we would like to spend furth= er work on updating and profiling CMP focusing on industrial use cases.

To get input, feedback and support from LAMPS we propose the followin= g charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.c= om> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ..

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

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

 

--_000_AM0PR10MB2402B5BB06E4FB59A8ECB16BFE060AM0PR10MB2402EURP_-- From nobody Mon May 20 08:10:36 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276631201A3 for ; Mon, 20 May 2019 08:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MW2Q49cmOgjI for ; Mon, 20 May 2019 08:10:26 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F038120170 for ; Mon, 20 May 2019 08:10:25 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4KFAOF0013149 for ; Mon, 20 May 2019 11:10:25 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x4KFAOF0013149 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1558365025; bh=L0736UkDeDnDhv3G3lY4QJFu9UmErWKGIDSH59XUt64=; h=From:To:Subject:Date:From; b=ZEiDANrFRU5n48iFihd0q8+7uC0ftvTBVTT5isJO7ndpp1kolfAOwcxACIM0JKGcA QEexVnkc7NklsNTwuFVi1uRQftH2T9dNc4mx4eStCmE2HfPzl9Vgm2sR/m77JgVwTV YvSwP7Yx+pD302igxUxhfzYL31GxRdG9eg71lF0g= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x4KFA6Gq030855 for ; Mon, 20 May 2019 11:10:06 -0400 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0439.000; Mon, 20 May 2019 11:10:06 -0400 From: Roman Danyliw To: "spasm@ietf.org" Thread-Topic: 2nd AD Review: draft-ietf-lamps-hash-of-root-key-cert-extn-05 Thread-Index: AdUPG0jfMZh9av8bTgu763jbPOGi/w== Date: Mon, 20 May 2019 15:10:05 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B336DBC6@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [lamps] 2nd AD Review: draft-ietf-lamps-hash-of-root-key-cert-extn-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 15:10:28 -0000 Hi! Thanks for iteration and improvements from IETF LC discussion. I'm pick-up= this draft from the AD hand-off (and did another review despite being in t= he "Waiting for Writeup" state). It is in good shape. I have the followi= ng nits: (1) (Editorial Nit) Section 1.2. "Generated" doesn't seem like the right w= ord to describe a formal notation/syntax for a certificate. (2) Section 3. Per "The definition of EXTENSION and HashAlgorithm can be f= ound in [RFC5912]", HashAlgorithm isn't referenced in the ASN.1 syntax. I = believe it should be s/HashAlgorithm/AlgorithmIdentifier/. I'm advancing the draft to IESG Evaluation. Roman From nobody Mon May 20 12:25:54 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D5B1200CD for ; Mon, 20 May 2019 12:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=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 LQ2iQXgxX2Tc for ; Mon, 20 May 2019 12:25:50 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 135C6120103 for ; Mon, 20 May 2019 12:25:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 95141300AB2 for ; Mon, 20 May 2019 15:06:31 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WO5rD5WwimGc for ; Mon, 20 May 2019 15:06:30 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 421203005C6; Mon, 20 May 2019 15:06:30 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Russ Housley In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B336DBC6@marathon> Date: Mon, 20 May 2019 15:25:47 -0400 Cc: "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC01B336DBC6@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [lamps] 2nd AD Review: draft-ietf-lamps-hash-of-root-key-cert-extn-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 19:25:52 -0000 I am pleased to fix these. I'll wait for any other comments from the = IESG Evaluation. Russ > On May 20, 2019, at 11:10 AM, Roman Danyliw wrote: >=20 > Hi! >=20 > Thanks for iteration and improvements from IETF LC discussion. I'm = pick-up this draft from the AD hand-off (and did another review despite = being in the "Waiting for Writeup" state). It is in good shape. I = have the following nits: >=20 > (1) (Editorial Nit) Section 1.2. "Generated" doesn't seem like the = right word to describe a formal notation/syntax for a certificate. >=20 > (2) Section 3. Per "The definition of EXTENSION and HashAlgorithm can = be found in [RFC5912]", HashAlgorithm isn't referenced in the ASN.1 = syntax. I believe it should be s/HashAlgorithm/AlgorithmIdentifier/. >=20 > I'm advancing the draft to IESG Evaluation. >=20 > Roman >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Mon May 20 13:40:29 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CDC120026; Mon, 20 May 2019 13:40:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-lamps-rfc6844bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <155838482753.12864.7318594608163615168.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2019 13:40:27 -0700 Archived-At: Subject: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-rfc6844bis-06=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2019 20:40:27 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-lamps-rfc6844bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you all for the work put into this document. I appreciate the section 7 about the differences with RFC 6844. == COMMENTS == -- Section 2.2 -- "Domain Name: The label assigned to a node in the Domain Name System." AFAIK RFC 1034 defines it differently "The domain name of a node is the list of the labels on the path from the node to the root of the tree" Or are we talking about different "domain names" ? "Wildcard domain name": it would be interesting to define not only the syntax but also the semantic do those wildcard domain names. -- Section 3 -- While I am not a security expert, a TLD could add a CAA forcing all its FQDN to either use the CA defined in the TLD CAA RRset or add a per FQDN CAA (which may raise the bar for small not-so-managed domains which otherwise could have used a cheap and easy CA such as letsencrypt). Is it really good to climb the DNS tree up to the TLD? Just curious. == NITS == -- Section 3 -- I would have preferred a recursive definition rather than an interative algorithm but this is a matter of taste ;-) From nobody Tue May 21 05:26:08 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EC0120118 for ; Tue, 21 May 2019 05:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 AdN2HM5O0zF5 for ; Tue, 21 May 2019 05:26:02 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7605D120059 for ; Tue, 21 May 2019 05:26:02 -0700 (PDT) Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x4LCPxf6013535 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 May 2019 14:26:00 +0200 Received: from DEFTHW99ERJMSX.ww902.siemens.net (defthw99erjmsx.ww902.siemens.net [139.22.70.135]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id x4LCPxu8029165 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 May 2019 14:25:59 +0200 Received: from DEFTHW99ER6MSX.ww902.siemens.net (139.22.70.65) by DEFTHW99ERJMSX.ww902.siemens.net (139.22.70.135) with Microsoft SMTP Server (TLS) id 14.3.435.0; Tue, 21 May 2019 14:25:59 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.220]) by DEFTHW99ER6MSX.ww902.siemens.net ([139.22.70.65]) with mapi id 14.03.0435.000; Tue, 21 May 2019 14:25:58 +0200 From: "Fries, Steffen" To: Russ Housley CC: "spasm@ietf.org" , "Brockhaus, Hendrik" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQJlFWLwAC/a9LA= Date: Tue, 21 May 2019 12:25:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.50] Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B337826F96E9EDENBGAT9EJ5MSXw_" MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 12:26:06 -0000 --_000_E6C9F0E527F94F4692731382340B337826F96E9EDENBGAT9EJ5MSXw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, Just to add to the applicability/usability of the lightweight CMP profile. = We are currently in the process of implementing this approach, based on ope= nSSL. Best regards Steffen From: Brockhaus, Hendrik (CT RDA ITS SEA-DE) Sent: Montag, 20. Mai 2019 15:43 To: Russ Housley Cc: Fries, Steffen (CT RDA ITS) ; spasm@ietf.org Subject: AW: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Russ We discussed my proposal on the mailing list. I feel there is quite some su= pport. Tomas, Max and Martin supported the activity. There were some questions and= concerns from Panos, that I hopefully could clarify. What is the next step? Hendrik Von: Spasm > Im Auftr= ag von [ext] Brockhaus, Hendrik Gesendet: Mittwoch, 8. Mai 2019 11:10 An: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; Fri= es, Steffen (CT RDA ITS) > Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_E6C9F0E527F94F4692731382340B337826F96E9EDENBGAT9EJ5MSXw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ,

 

Just to add to the applicability/usability of the light= weight CMP profile. We are currently in the process of implementing this ap= proach, based on openSSL.

 

Best regards

Steffen

 

From: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@si= emens.com>
Sent: Montag, 20. Mai 2019 15:43
To: Russ Housley <housley@vigilsec.com>
Cc: Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>; s= pasm@ietf.org
Subject: AW: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ

&nbs= p;

We discussed my proposal on the mailing list. I feel there is quite s= ome support.

Tomas, Max and Martin supported the activity. There were some questio= ns and concerns from Panos, that I hopefully could clarify.

 

What is the next step?

 

Hendrik

 

Von: Spasm <spasm-bounces@ietf.org> Im Auftrag von [ext] Brockhaus, Hendrik
Gesendet: Mittwoch, 8. Mai 2019 11:10
An: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, = all,

&nbs= p;

as discussed at IETF104 and on this list we would like to spend furth= er work on updating and profiling CMP focusing on industrial use cases.

To get input, feedback and support from LAMPS we propose the followin= g charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.c= om> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ..

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

_______________________________________________ Spasm mailing list
Spasm@ietf.org
https://www.ietf.org/mailma= n/listinfo/spasm

 

--_000_E6C9F0E527F94F4692731382340B337826F96E9EDENBGAT9EJ5MSXw_-- From nobody Tue May 21 08:46:15 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F86312001E; Tue, 21 May 2019 08:46:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155845357244.2344.17897733427530646770.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2019 08:46:12 -0700 Archived-At: Subject: [lamps] Magnus Westerlund's No Objection on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 15:46:13 -0000 Magnus Westerlund has entered the following ballot position for draft-ietf-lamps-hash-of-root-key-cert-extn-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I would appreciate if one could explain why this document is being published as an informational one. I am sure there are reasons, but they are not evident from the writeup. From nobody Tue May 21 10:53:58 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7416112018A for ; Tue, 21 May 2019 10:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbSqsdtfPsko for ; Tue, 21 May 2019 10:53:51 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE596120192 for ; Tue, 21 May 2019 10:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9F913300AE8 for ; Tue, 21 May 2019 13:28:23 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4Q812W7iiCRt for ; Tue, 21 May 2019 13:28:21 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 1900E300471; Tue, 21 May 2019 13:28:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <155845357244.2344.17897733427530646770.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2019 13:47:38 -0400 Cc: IESG , spasm@ietf.org, lamps-chairs@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, tim.hollebeek@digicert.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <155845357244.2344.17897733427530646770.idtracker@ietfa.amsl.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Magnus Westerlund's No Objection on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 17:53:57 -0000 Magnus: This was added to the LAMPS WG charter as an informational document in = the middle of 2018, and there was a very long IETF Last Call at the = beginning of this year, with the issues raised being sorted by the end = of February. Please do not seek another IETF Last Call in order to = produce an standards-track RFC. This document is useful in some PKI environments, but not all. The = Operational Considerations (Section 5) tries to help a Root CA that is = standing up a new trust anchor determine whether it should use this = extension or not. Russ > On May 21, 2019, at 11:46 AM, Magnus Westerlund via Datatracker = wrote: >=20 > Magnus Westerlund has entered the following ballot position for > draft-ietf-lamps-hash-of-root-key-cert-extn-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-ex= tn/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I would appreciate if one could explain why this document is being = published as > an informational one. I am sure there are reasons, but they are not = evident > from the writeup. >=20 >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm From nobody Tue May 21 13:45:55 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADA81200E9 for ; Tue, 21 May 2019 13:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpWamo1NoNng for ; Tue, 21 May 2019 13:45:52 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6126B12001A for ; Tue, 21 May 2019 13:45:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 48D9E300A46 for ; Tue, 21 May 2019 16:26:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DzgIxuyfGoAQ for ; Tue, 21 May 2019 16:26:33 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 2457D300474; Tue, 21 May 2019 16:26:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B336DBC6@marathon> Date: Tue, 21 May 2019 16:45:50 -0400 Cc: "spasm@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC01B336DBC6@marathon> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] 2nd AD Review: draft-ietf-lamps-hash-of-root-key-cert-extn-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2019 20:45:54 -0000 Roman: I have made these changes in my edit buffer. Let me know if they do not = resolve your concerns. > (1) (Editorial Nit) Section 1.2. "Generated" doesn't seem like the = right word to describe a formal notation/syntax for a certificate. Certificates [RFC5280] use ASN.1 [X680]; certificates are always encoded with the Distinguished Encoding Rules (DER) [X690]. > (2) Section 3. Per "The definition of EXTENSION and HashAlgorithm can = be found in [RFC5912]", HashAlgorithm isn't referenced in the ASN.1 = syntax. I believe it should be s/HashAlgorithm/AlgorithmIdentifier/. I chose to fix it in another way. RFC 5912 also has a definition of = HashAlgorithm, which is an AlgorithmIdentifier that is constrained to = the set of DIGEST-ALGORITHMs: HashAlgorithm ::=3D AlgorithmIdentifier{DIGEST-ALGORITHM, {HashAlgorithms}} The bits on the wire do not change with this approach. The ASN.1 in this document becomes: ext-HashOfRootKey EXTENSION ::=3D { -- Only in Root CA = certificates SYNTAX HashedRootKey IDENTIFIED BY id-ce-hashOfRootKey CRITICALITY {FALSE} } HashedRootKey ::=3D SEQUENCE { hashAlg HashAlgorithm, -- Hash algorithm used hashValue OCTET STRING } -- Hash of DER-encoded -- SubjectPublicKeyInfo id-ce-hashOfRootKey ::=3D OBJECT IDENTIFIER { 1 3 6 1 4 1 51483 2 1 = } Russ From nobody Tue May 21 18:07:34 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C78120103; Tue, 21 May 2019 18:07:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joel Halpern Message-ID: <155848724103.2726.16872458550460720675@ietfa.amsl.com> Date: Tue, 21 May 2019 18:07:21 -0700 Archived-At: Subject: [lamps] Genart telechat review of draft-ietf-lamps-hash-of-root-key-cert-extn-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 01:07:21 -0000 Reviewer: Joel Halpern Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-lamps-hash-of-root-key-cert-extn-05 Reviewer: Joel Halpern Review Date: 2019-05-21 IETF LC End Date: None IESG Telechat date: 2019-05-30 Summary: This Internet Draft is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A From nobody Wed May 22 01:04:46 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D131200A2; Wed, 22 May 2019 01:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 9U0QkBa7bYBN; Wed, 22 May 2019 01:04:34 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70077.outbound.protection.outlook.com [40.107.7.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20BB11200BA; Wed, 22 May 2019 01:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q/ud3HEF1mcSgaHyfAMuh/OQDiSn2ConVm2w6vRgMnw=; b=n0tIWlrIE1fC9S3pgaMftis6UMQjVNtXDeaQ0NbrmPN3hH5OoL7R7iRgIPxvd3QmMkTqEaViKMnYhTgzHOlCothV3Nm/XSQe1lkTol4CiqCIOe1xfNCOQzWVAhyKZSgScBAL1dvPu9gFjzku5mXXjjMYsh1MSDFqHmUMYrbS/VU= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2732.eurprd07.prod.outlook.com (10.168.188.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.7; Wed, 22 May 2019 07:49:02 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::896a:7ada:8bc9:d99d%6]) with mapi id 15.20.1922.016; Wed, 22 May 2019 07:49:02 +0000 From: Magnus Westerlund To: Russ Housley CC: IESG , "spasm@ietf.org" , "lamps-chairs@ietf.org" , "draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org" , "tim.hollebeek@digicert.com" Thread-Topic: [lamps] Magnus Westerlund's No Objection on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with COMMENT) Thread-Index: AQHVD+xax52CISy/oESAmF/zUex3Ag== Date: Wed, 22 May 2019 07:49:02 +0000 Message-ID: References: <155845357244.2344.17897733427530646770.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.81] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 97d527c0-d83b-4407-d5c5-08d6de89f52a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2732; x-ms-traffictypediagnostic: HE1PR0701MB2732: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(39860400002)(376002)(366004)(189003)(199004)(81156014)(81166006)(8676002)(256004)(14444005)(6916009)(14454004)(508600001)(33656002)(74316002)(8936002)(68736007)(71190400001)(71200400001)(966005)(229853002)(99286004)(66476007)(66946007)(76116006)(66446008)(66556008)(6116002)(3846002)(73956011)(64756008)(2906002)(53936002)(7696005)(6506007)(53546011)(76176011)(102836004)(25786009)(305945005)(7736002)(6246003)(4326008)(6436002)(6306002)(9686003)(66066001)(55016002)(54906003)(26005)(86362001)(316002)(446003)(44832011)(486006)(476003)(186003)(5660300002)(52536014); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2732; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: t+wkPuYCWc7ATTmBdKts3FP0H47GNZFvWtm6+F0oim5Z5D+JbBl2/YJFxmmGA+SZGLeoWVWzThYB4mLBTahqhlFPaszCwPWFsSG9KpiJy4Dr0m5fByxnmOrv/rcPhQMLwXkycZKQzNY2XnYjINkRCSg+rqMAQQX4Nc7AbBkLGmArGNQhffCpKn80ttnrXq+dgZqTREJqdKe2bHmjbg8UVi8uDH+1X8zFLsxDagKRd9eQ2UiZ8BYEUwlQ2VWW6wfd0bo2upxYpL4g8U3H0+JoyZGFVQlm8+uxmYd54l8gvMTJWHn61H3otklmEFFJKrShX5oTOa/VWWH7xNrj5jFLddCa3gAnAb/pIqx6kg/A/sxPTuXsG8qSFtm2oRkNFpdToH747jCdaMhnzfiJBqtsibV4aJhXW1UPmSqYpGfh+B0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 97d527c0-d83b-4407-d5c5-08d6de89f52a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2019 07:49:02.3153 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: magnus.westerlund@ericsson.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2732 Archived-At: Subject: Re: [lamps] Magnus Westerlund's No Objection on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 08:04:38 -0000 Hi,=0A= =0A= Don't worry, I was just asking for the reasoning. It reads very much as=0A= a standards track document, and I found nothing in the IESG writeup that=0A= explained it, that is why I asked. Also, I am lacking the area=0A= understanding to determine if there are any formality issues with=0A= publishing this extension as an informational RFC.=0A= =0A= I think this is more a note to the sponsoring ADs that they may have to=0A= consider if there will be questions about intended status and needs to=0A= motivate that in the writeup. I will take this up with the IESG.=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= On 2019-05-21 19:47, Russ Housley wrote:=0A= > Magnus:=0A= >=0A= > This was added to the LAMPS WG charter as an informational document in th= e middle of 2018, and there was a very long IETF Last Call at the beginning= of this year, with the issues raised being sorted by the end of February. = Please do not seek another IETF Last Call in order to produce an standards= -track RFC.=0A= >=0A= > This document is useful in some PKI environments, but not all. The Opera= tional Considerations (Section 5) tries to help a Root CA that is standing = up a new trust anchor determine whether it should use this extension or not= .=0A= >=0A= > Russ=0A= >=0A= >=0A= >> On May 21, 2019, at 11:46 AM, Magnus Westerlund via Datatracker wrote:=0A= >>=0A= >> Magnus Westerlund has entered the following ballot position for=0A= >> draft-ietf-lamps-hash-of-root-key-cert-extn-05: No Objection=0A= >>=0A= >> When responding, please keep the subject line intact and reply to all=0A= >> email addresses included in the To and CC lines. (Feel free to cut this= =0A= >> introductory paragraph, however.)=0A= >>=0A= >>=0A= >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htm= l=0A= >> for more information about IESG DISCUSS and COMMENT positions.=0A= >>=0A= >>=0A= >> The document, along with other ballot positions, can be found here:=0A= >> https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-= extn/=0A= >>=0A= >>=0A= >>=0A= >> ----------------------------------------------------------------------= =0A= >> COMMENT:=0A= >> ----------------------------------------------------------------------= =0A= >>=0A= >> I would appreciate if one could explain why this document is being publi= shed as=0A= >> an informational one. I am sure there are reasons, but they are not evid= ent=0A= >> from the writeup.=0A= >>=0A= >>=0A= >> _______________________________________________=0A= >> Spasm mailing list=0A= >> Spasm@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/spasm=0A= >=0A= =0A= -- =0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Wed May 22 10:35:37 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5141202BE; Wed, 22 May 2019 10:35:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155854652269.11209.18166503524488589778.idtracker@ietfa.amsl.com> Date: Wed, 22 May 2019 10:35:22 -0700 Archived-At: Subject: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-lamps-hash-of-root-key-cert-extn-05=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 17:35:35 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-lamps-hash-of-root-key-cert-extn-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why is the intended status informational? Unfortunately, this is not further explained in the shepherd write-up. What was the discussion in the group and why was informational selected? As this doc defines a protocol extension, informational does not seem appropriate for me. Should it be experimental instead? Quick question/comment: The document mentions two “error” cases where a new self-signed certificate needs to be deployed. If that is an option that always need to be taken into account, the benefits of this mechanism are less clear to me. What is the exact attack scenarios this mechanism tries to protect? From nobody Wed May 22 11:13:25 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC2F120159 for ; Wed, 22 May 2019 11:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD7BNqC1y7A9 for ; Wed, 22 May 2019 11:13:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FC6512006E for ; Wed, 22 May 2019 11:13:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 72FEA300AE8 for ; Wed, 22 May 2019 13:54:03 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hMM69acuxV_F for ; Wed, 22 May 2019 13:54:01 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 478C9300471; Wed, 22 May 2019 13:54:01 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_317D3B42-E37A-4F05-A8FC-7B74F35E89B2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 22 May 2019 14:13:18 -0400 In-Reply-To: <155854652269.11209.18166503524488589778.idtracker@ietfa.amsl.com> Cc: IESG , Tim Hollebeek , SPASM To: =?utf-8?Q?Mirja_K=C3=BChlewind?= References: <155854652269.11209.18166503524488589778.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-lamps-hash-of-root-key-cert-extn-05=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 18:13:24 -0000 --Apple-Mail=_317D3B42-E37A-4F05-A8FC-7B74F35E89B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Mirja: > Why is the intended status informational? Unfortunately, this is not = further > explained in the shepherd write-up. What was the discussion in the = group and > why was informational selected? As this doc defines a protocol = extension, > informational does not seem appropriate for me. Should it be = experimental > instead? This document was originally expected to be published on the Independent = Stream, but the Security Area Director at the time asked the ISE to send = the document to the LAMPS WG. Since it was already submitted to the = Independent Stream for publication as Informational RFC, the topic never = came up about a different publication status. The LAMPS WG discussion started here: = https://mailarchive.ietf.org/arch/msg/spasm/o7aDwt5VMXCyL5UeLHrZxrdQjaA = > Quick question/comment: The document mentions two =E2=80=9Cerror=E2=80=9D= cases where a new > self-signed certificate needs to be deployed. If that is an option = that always > need to be taken into account, the benefits of this mechanism are less = clear to > me. What is the exact attack scenarios this mechanism tries to = protect? Deploying a new self-signed certificate is a much more complex task. = While this is the fallback situation if things go wrong, the deployment = of replacement self-signed certificate is much simpler when things work. Russ --Apple-Mail=_317D3B42-E37A-4F05-A8FC-7B74F35E89B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Mirja:

Why is the = intended status informational? Unfortunately, this is not further
explained in the shepherd write-up. What was the discussion = in the group and
why was informational selected? As this = doc defines a protocol extension,
informational does not = seem appropriate for me. Should it be experimental
instead?

This document was originally expected to be published = on the Independent Stream, but the Security Area Director at the time = asked the ISE to send the document to the LAMPS WG. Since it was already = submitted to the Independent Stream for publication as Informational = RFC, the topic never came up about a different publication status.

The LAMPS WG discussion started here: https://mailarchive.ietf.org/arch/msg/spasm/o7aDwt5VMXCyL5UeLHr= ZxrdQjaA

Quick question/comment: The = document mentions two =E2=80=9Cerror=E2=80=9D cases where a new
self-signed certificate needs to be deployed. If that is an = option that always
need to be taken into account, the = benefits of this mechanism are less clear to
me. What is = the exact attack scenarios this mechanism tries to protect?

Deploying = a new self-signed certificate is a much more complex task.  While = this is the fallback situation if things go wrong, the deployment of = replacement self-signed certificate is much simpler when things = work.

Russ


= --Apple-Mail=_317D3B42-E37A-4F05-A8FC-7B74F35E89B2-- From nobody Wed May 22 19:06:34 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1606812011B; Wed, 22 May 2019 19:06:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Qin Wu via Datatracker To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc6844bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.96.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Qin Wu Message-ID: <155857717903.11139.12463391706861915813@ietfa.amsl.com> Date: Wed, 22 May 2019 19:06:19 -0700 Archived-At: Subject: [lamps] Opsdir telechat review of draft-ietf-lamps-rfc6844bis-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 02:06:19 -0000 Reviewer: Qin Wu Review result: Ready I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft substitutes RFC6844 and defines the syntax of the CAA record and rules for processing CAA records by certificate issuers.It is well written, fix a lot of bugs in RFC6844 and simplify the mechanism in RFC6844, I believe it is ready for publication. Major issue: Not found Minor issue: Section 3, first paragraph: s/ CAA Resource Record set/CAA RRSet Section 4.3 I am not a DNS expert, Not sure why Wildcard Domain Name Is not part of RRSet in the several examples? Section 8 I think IANA should replace RFC6844 with RFC number assigned to this document in the the Certification Authority Restriction Flags registry and Certification Authority Restriction Properties registry. From nobody Mon May 27 06:00:04 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BF412015E; Mon, 27 May 2019 05:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Montville via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Montville Message-ID: <155896198526.742.8687531313314399857@ietfa.amsl.com> Date: Mon, 27 May 2019 05:59:45 -0700 Archived-At: Subject: [lamps] Secdir telechat review of draft-ietf-lamps-hash-of-root-key-cert-extn-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 12:59:46 -0000 Reviewer: Adam Montville Review result: Ready >From a SECDIR perspective, this draft is ready (feel free to see the last review on the 03 draft [1]. Between 03 and 05 some minor changes were made and the operational considerations section has been expanded. [1] https://datatracker.ietf.org/doc/review-ietf-lamps-hash-of-root-key-cert-extn-03-secdir-lc-montville-2019-01-08/ From nobody Mon May 27 06:04:01 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9338B12013D for ; Mon, 27 May 2019 06:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMQizrPqY8W0 for ; Mon, 27 May 2019 06:03:56 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60067.outbound.protection.outlook.com [40.107.6.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF4FB120113 for ; Mon, 27 May 2019 06:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZFnXFu84zW715gdCJkJvy7QRvhCW1zFW+bzQCP/tQYg=; b=a+T4XCopb67llwY/VYeCRAR5NOSHd6DjDwaVTOJ3RpgWXjZGVUb57mkKCscBzug/Yw7fpxT0+lMWZyFO+xcYTw6Kb3kryPEVvNgjCYkD9f2Ya/GS3oTk0GfIKYwXrUhijBq2mx5UdrLSD9pd10nMOqbMn+IG8Gxj+YnfVYgdTXM= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2659.EURPRD10.PROD.OUTLOOK.COM (20.178.119.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.18; Mon, 27 May 2019 13:03:53 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1922.021; Mon, 27 May 2019 13:03:53 +0000 From: "Brockhaus, Hendrik" To: Russ Housley CC: "steffen.fries@siemens.com" , "spasm@ietf.org" Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQJlFWLwAV6eFhA= Date: Mon, 27 May 2019 13:03:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 658cdf2f-03ba-4337-f30e-08d6e2a3c51d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR10MB2659; x-ms-traffictypediagnostic: AM0PR10MB2659: x-ms-exchange-purlcount: 1 x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(39860400002)(366004)(136003)(53754006)(199004)(189003)(7696005)(186003)(14454004)(54906003)(606006)(76176011)(53936002)(76116006)(476003)(64756008)(966005)(15650500001)(478600001)(5660300002)(99286004)(2420400007)(7110500001)(19627235002)(55016002)(14444005)(86362001)(66556008)(236005)(486006)(66476007)(66446008)(68736007)(25786009)(4326008)(9686003)(54896002)(6506007)(256004)(6306002)(53546011)(26005)(102836004)(74316002)(7736002)(66066001)(6436002)(2906002)(71190400001)(81166006)(71200400001)(81156014)(8936002)(8676002)(3846002)(6116002)(790700001)(446003)(11346002)(52536014)(73956011)(66946007)(561944003)(6916009)(316002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2659; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fkdHVpN9DSEwcXM+Hg9s9T1hKSAeJw1VhtWlDJhLBQIsxtKPCDpryOaSdij3PWY/9RzhAeOMUl1UsmR0d3rfvKOb5rJZCLrd3TRlJxU1Ihw4qOscK+gr99IE9C13LKOPvyHBiUBt8BGnESpzm+cXcXlchbbPi2X8fbWbQZKU7X9Wo1j3LiyDqtgD9iZxXz2RVz93LBX+nWddzLE9m3GYH4Tv3PrGLQRNfI+xodvyq8NhMHDRIDkaOu+ESClTiBIlGxrd/2EHiDpDXeKGLpDW26OooNYjsCSs99BO/j3TbP7NrthdbCskOGmlD3Z0NjIzm7AnXFZb+PGqlUSloMvtwPZ7evwxuCmmycKz2JrkGt4QySAb8N52lZawmvDIIz0VJGxN8eW7zD8neBqhEKyuXtYT9YFHD7hUurw7eeRwQp0= Content-Type: multipart/alternative; boundary="_000_AM0PR10MB2402C7C1AAA09EABF047F0CEFE1D0AM0PR10MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 658cdf2f-03ba-4337-f30e-08d6e2a3c51d X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2019 13:03:53.3355 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hendrik.brockhaus@siemens.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2659 Archived-At: Subject: Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 13:04:00 -0000 --_000_AM0PR10MB2402C7C1AAA09EABF047F0CEFE1D0AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ Did you have the time to look into my mail below? I would like to push this topic further forward. Hendrik Von: Brockhaus, Hendrik (CT RDA ITS SEA-DE) Gesendet: Montag, 20. Mai 2019 15:43 An: Russ Housley Cc: Fries, Steffen (CT RDA ITS) ; spasm@ietf.org Betreff: AW: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Russ We discussed my proposal on the mailing list. I feel there is quite some su= pport. Tomas, Max and Martin supported the activity. There were some questions and= concerns from Panos, that I hopefully could clarify. What is the next step? Hendrik Von: Spasm > Im Auftr= ag von [ext] Brockhaus, Hendrik Gesendet: Mittwoch, 8. Mai 2019 11:10 An: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; Fri= es, Steffen (CT RDA ITS) > Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document.. @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_AM0PR10MB2402C7C1AAA09EABF047F0CEFE1D0AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ

&nbs= p;

Did you have the time to look into my mail below?

I would like to push this topic further forward.

 

Hendrik

 

Von: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <= br> Gesendet: Montag, 20. Mai 2019 15:43
An: Russ Housley <housley@vigilsec.com>
Cc: Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>; s= pasm@ietf.org
Betreff: AW: Proposed Re-Chartering Text for CMP updates and lightwe= ight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ

&nbs= p;

We discussed my proposal on the mailing list. I feel there is quite s= ome support.

Tomas, Max and Martin supported the activity. There were some questio= ns and concerns from Panos, that I hopefully could clarify.

 

What is the next step?

 

Hendrik

 

Von: Spasm <spasm-bounces@ietf.org> Im Auftrag von [ext] Brockhaus, Hendrik
Gesendet: Mittwoch, 8. Mai 2019 11:10
An: spasm@ietf.org; Russ Housl= ey <housley@vigilsec.com>=
Cc: Jim Schaad <ietf@au= gustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lig= htweight profile (RE: Follow-up on lightweight CMP profile)

 

Hi Russ, = all,

&nbs= p;

as discussed at IETF104 and on this list we would like to spend furth= er work on updating and profiling CMP focusing on industrial use cases.

To get input, feedback and support from LAMPS we propose the followin= g charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von: Russ Housley <housley@vigilsec.com>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad= <ietf@augustcellars.com&g= t;; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on lightweight CMP profile=

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.c= om> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ..

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

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

 

--_000_AM0PR10MB2402C7C1AAA09EABF047F0CEFE1D0AM0PR10MB2402EURP_-- From nobody Mon May 27 06:31:33 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B3312015F for ; Mon, 27 May 2019 06:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2lVLVkv_8QS for ; Mon, 27 May 2019 06:31:29 -0700 (PDT) Received: from beechnut.cse-cst.gc.ca (beechnut.cse-cst.gc.ca [205.193.218.37]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B27312001A for ; Mon, 27 May 2019 06:31:29 -0700 (PDT) From: "Hammell, Jonathan F" To: "'spasm@ietf.org'" Thread-Topic: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk Thread-Index: AdUUjUhsTWU98srlTk2AlTzaw5oH1A== Date: Mon, 27 May 2019 13:31:24 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-classification: UNCLASSIFIED Content-Type: multipart/mixed; boundary="_002_ba3c46ac49d84bf892c04051f5fea3c5cybergcca_" MIME-Version: 1.0 Message-Id: <20190527133129.7B27312001A@ietfa.amsl.com> Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 13:31:32 -0000 --_002_ba3c46ac49d84bf892c04051f5fea3c5cybergcca_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED Sorry for the late comment. My colleagues and I did review the draft and w= e have no suggestions for text changes. We also produced a ProVerif model = (attached) in an attempt to verify some of the cryptographic properties. D= etails are below. Let me know if you have any questions or issues. # Assumptions/limitations The model is limited to the Key Agreement algorithm and is bounded with two= hardwired originators and hardwired recipients.=20 =20 We assume the DH key exchange is broken using a quantum computer such that = the recipient private keys are known at the outset. We have modeled this by= revealing the recipient's DH private key on the channel. All recipients have DH certificates signed by a trusted CA. These are share= d with all at beginning of the protocol.=20 In an effort to model configuration choices of key encryption and kdf algor= ithms, we included settings for using strong or weak algorithms (in the qua= ntum perspective). The model allows the attacker to modify the settings to = both the originator and the receivers' algorithm configuration to use quant= um-vulnerable algorithms. # Security queries Our interpretation of the draft is that it is attempting to solve the probl= em of maintaining the confidentiality of an encrypted cek from an opponent = with the ability to break the DH public keys with a quantum computer. There= fore our model is limited to proving confidentiality of the cek in the face= of such an attacker. The model contains two types of queries: 1. Sanity - Whenever a sender s sends an encrypted version of cek to an int= ended recipient r then recipient r receives the same cek from sender s . 2. Confidentiality- An attacker cannot learn the cek during a protocol run= unless the sender uses weak crypto (in the quantum perspective). # Running the model proverif -graph . Using_PSK_in_CMS_Keyagree.pv ProVerif spits out a lot of info, but the important statements about the qu= eries are prefixed by the string "RESULT". --- Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk Russ Housley Fri, 10 May 2019 15:00 UTChttps://maila= rchive.ietf.org/arch/browse/spasm/?q=3Dmix-with-psk=20 The only comment that I received is to add at the top of the = ASN.1 module and at the bottom of the ASN.1 module. I will do = that now. Russ > On May 10, 2019, at 10:52 AM, Tim Hollebeek =20 > It appears no one has any further comments on this document, and it is re= ady to proceed. > =20 > -Tim > =20 > From: Spasm > On Behalf Of Tim Hollebeek > Sent: Friday, April 19, 2019 10:45 AM > To: SPASM > > Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk > =20 > This is the LAMPS WG Last Call for "Using Pre-Shared Key (PSK) in the Cry= ptographic Message Syntax (CMS)" . Plea= se review the document and send your comments to the list by 6 May 2019. > =20 > The datatracker page for the document is https://datatracker.ietf.org/doc= /draft-ietf-lamps-cms-mix-with-psk/ =20 > Thanks, > =20 > Tim --_002_ba3c46ac49d84bf892c04051f5fea3c5cybergcca_ Content-Type: application/octet-stream; name="Using_PSK_in_CMS_Keyagree.pv" Content-Description: Using_PSK_in_CMS_Keyagree.pv Content-Disposition: attachment; filename="Using_PSK_in_CMS_Keyagree.pv"; size=11632; creation-date="Mon, 27 May 2019 13:28:07 GMT"; modification-date="Fri, 24 May 2019 18:46:36 GMT" Content-Transfer-Encoding: base64 KCpQcm9WZXJpZiBtb2RlbCBmb3IgdGhlICJVc2luZyBQU0sgaW4gdGhlIENNUyIgZHJhZnQgKikK KCpUaGlzIG1vZGVsIGlzIGFuIHVwZGF0ZSBvZiB0aGUga2V5IGFncmVlbWVudCBtZXRob2QgdG8g bWVldCB0aGUgbmV3IGRyYWZ0IHZlcnNpb24gMDMgKE1hcmNoIDIwMTggKSAqKQoKCigqIFByb3Rv Y29sIHZhcmlhYmxlIGRlZmluaXRpb25zICopCgooKiBEZWZpbmUgc3Ryb25nIG9yIHdlYWsgS0RG IGFuZCBLZW5jcnlwdGlvbiBpZHMgKikKdHlwZSBLREZJRC4KY29uc3QgSEtERjogS0RGSUQuCmNv bnN0IFdLREY6IEtERklELgp0eXBlIEtFbmNJRC4KY29uc3QgQUVTMjU2OktFbmNJRC4KY29uc3Qg QUVTMTI4OktFbmNJRC4KCnR5cGUgS0VLLgp0eXBlIEtESy4KKCpQU0sgc3R1ZmYgaW5jbHVkaW5n IHRoZSBzdHJ1Y3R1cmUgZm9yIHRoZSBQU0tPdGhlckluZm8gKikKdHlwZSBQU0tJRC4KdHlwZSBQ U0suCgoKKCpUaGVzZSBhcmUgdmFsdWVzIGZvciB0aGUgbmV3IENNU09SSWZvclBTS090aGVySW5m byB0eXBlICopCmNvbnN0ICBwc2tsZW46Yml0c3RyaW5nLgpjb25zdCAga2RrbGVuOmJpdHN0cmlu Zy4KY29uc3QgIHBza2xlbjI6Yml0c3RyaW5nLgpjb25zdCAga2RrbGVuMjpiaXRzdHJpbmcuCgoo KmtleU1nbXRhbGdUeXBlKikKY29uc3QgIGtleUFncmVlOmJpdHN0cmluZy4KY29uc3QgIGtleVRy YW5zOmJpdHN0cmluZy4KdHlwZSBJRC4KCigqZGVmaW5lIHRoZSBzdHJlbmd0aCBvZiB0aGUgY3J5 cHRvICopCmNvbnN0IFNJR05fTUFOREFUT1JZOiBib29sLgpjb25zdCBXRUFLX0NSWVBUTzogYm9v bC4KY29uc3QgV0VBS19LREY6Ym9vbC4KCnR5cGUgSERSLgp0eXBlIENNU1ZlcnNpb24uCmNvbnN0 IENNU1ZlcnNpb25fMDpDTVNWZXJzaW9uLgoKCmNvbnN0IHNob3J0a2V5OmJpdHN0cmluZy4KY29u c3QgbG9uZ2tleTpiaXRzdHJpbmcuCmNvbnN0IFNBTFQ6Yml0c3RyaW5nLgoKCigqQ3J5cHRvIEZ1 bmN0aW9uIGRlZmluaXRpb25zICopCgooKiBBc3ltbWV0cmljIEVuY3J5cHRpb24gKikKdHlwZSBw cml2a2V5LgpmdW4gcHJpdmtleTJiaXRzKHByaXZrZXkpOiBiaXRzdHJpbmcgW3R5cGVDb252ZXJ0 ZXJdLgoKdHlwZSBwdWJrZXkuCmZ1biBwdWJrZXkyYml0cyhwdWJrZXkpOiBiaXRzdHJpbmcgW3R5 cGVDb252ZXJ0ZXJdLgpmdW4gYml0czJwdWJrZXkoYml0c3RyaW5nKTogcHVia2V5IFt0eXBlQ29u dmVydGVyXS4KCmZ1biBwayhwcml2a2V5KTogcHVia2V5LgpmdW4gcHViZW5jKHB1YmtleSxiaXRz dHJpbmcpOmJpdHN0cmluZy4KZnVuIHNpZ24ocHJpdmtleSwgYml0c3RyaW5nKTogYml0c3RyaW5n LgpyZWR1YyBmb3JhbGwgazogcHJpdmtleSwgeDogYml0c3RyaW5nOyB2ZXJpZnkocGsoayksIHgs IHNpZ24oaywgeCkpID0gdHJ1ZS4KcmVkdWMgZm9yYWxsIG06IGJpdHN0cmluZywgazpwcml2a2V5 OyBwdWJkZWMoaywgcHViZW5jKHBrKGspLG0pKSA9IG0uCgpmdW4gcHVid2Vha19lbmMocHVia2V5 LGJpdHN0cmluZyk6Yml0c3RyaW5nLgpyZWR1YyBmb3JhbGwgbTpiaXRzdHJpbmcsIGs6cHJpdmtl eTsgcHVid2Vha19kZWMocHVid2Vha19lbmMocGsoayksIG0pKSA9IG0uCgooKiBTeW1tZXRyaWMg ZW5jcnlwdGlvbiAqKQp0eXBlIGtleS4KZnVuIHNlbmMoa2V5LCBiaXRzdHJpbmcpOiBiaXRzdHJp bmcuCnJlZHVjIGZvcmFsbCBrOmtleSwgbTpiaXRzdHJpbmc7IHNkZWMoaywgc2VuYyhrLG0pKSA9 IG0uCgpmdW4gc2VuY3dlYWsoa2V5LCBiaXRzdHJpbmcpOiBiaXRzdHJpbmcgW2RhdGFdLgpyZWR1 YyBmb3JhbGwgbTogYml0c3RyaW5nLCBrOmtleSA7IHNkZWN3ZWFrKHNlbmN3ZWFrKGssbSkpID0g bS4KCmZ1biBrZXkyYml0cyhrZXkpOiBiaXRzdHJpbmcgW3R5cGVDb252ZXJ0ZXJdLgpmdW4gYml0 czJrZXkoYml0c3RyaW5nKToga2V5IFt0eXBlQ29udmVydGVyXS4KCigqIERpZmZpZSBIZWxsbWFu ICopCnR5cGUgZWxlbWVudC4KICBjb25zdCBHOiBlbGVtZW50LgogIGZ1biBkaF9leHAoZWxlbWVu dCwgYml0c3RyaW5nKTogZWxlbWVudC4KICBlcXVhdGlvbiBmb3JhbGwgeDogYml0c3RyaW5nLCB5 OiBiaXRzdHJpbmc7CiAgICAgZGhfZXhwKGRoX2V4cChHLCB4KSwgeSkgPSBkaF9leHAoZGhfZXhw KEcseSkseCkuCgogIGZ1biBlMmJpdHMoZWxlbWVudCk6IGJpdHN0cmluZyBbdHlwZUNvbnZlcnRl cl0uCiAgZnVuIGIyZWxlbWVudChiaXRzdHJpbmcpOiBlbGVtZW50IFt0eXBlQ29udmVydGVyXS4K CgooKmtkZiBkZWZpbml0aW9ucyBpbmNsdWRpbmcgYSB3ZWFrIG9uZSB0aGF0IG5lZWRzIG9ubHkg dGhlIGtleSBhbmQgbm90IHRoZSBpbmZvKikKZnVuIGhrZGZfd2VhayhrZXkpOmtleS4KZnVuIGhr ZGYoa2V5LGJpdHN0cmluZyk6a2V5LgoKKCpDZXJ0aWZpY2F0ZSBzdHVmZiAqKQp0eXBlIGNlcnQu CmZ1biBiaXRzMmNlcnQoYml0c3RyaW5nKTogY2VydCBbdHlwZUNvbnZlcnRlcixkYXRhXS4KZnVu IGNlcnQyYml0cyhjZXJ0KTogYml0c3RyaW5nIFt0eXBlQ29udmVydGVyLGRhdGFdLgpjb25zdCBu b0NlcnQ6IGNlcnQuCgpmdW4gaW50ZXJuYWxfY2VydChJRCwgYml0c3RyaW5nLCBiaXRzdHJpbmcp OiBjZXJ0IFtkYXRhXS4KcmVkdWMgZm9yYWxsIGlkOklELCBuOmJpdHN0cmluZywgczpiaXRzdHJp bmc7IGNlcnRfcHVia2V5KGludGVybmFsX2NlcnQoaWQsIG4sIHMpKSA9IG4uCmxldGZ1biBta0Nl cnQoaTogSUQsIE46IGJpdHN0cmluZywgY2Ffa2V5OiBwcml2a2V5KSA9ICgKICAgICAgIGxldCBz aWduYXR1cmUgPSBzaWduKGNhX2tleSwgKGksIE4pKSBpbgogICAgICAgaW50ZXJuYWxfY2VydChp LCBOLCBzaWduYXR1cmUpCikuCgpsZXRmdW4gdmVyaWZ5X2NlcnQoS2NhOiBwdWJrZXksIGk6IElE LCBjOiBjZXJ0KSA9ICgKICAgICBsZXQgaW50ZXJuYWxfY2VydChqOiBJRCwgTjpiaXRzdHJpbmcs IHNpZzogYml0c3RyaW5nKSA9IGMgaW4KICAgICAgIChpID0gaiAmJiB2ZXJpZnkoS2NhLCAoaiwg TiksIHNpZykpCikuCgoKKCpUaGlzIGlzIHRoZSBnbG9iYWwgY2VrIHRoYXQgd2Ugd2FudCB0byBw cm90ZWN0ICopCigqbm90IGlkZWFsIHVzaW5nIGdsb2JhbCBidXQgaXQgaGVscHMgd2l0aCBjaGVj a3MgKikKY29uc3QgY2VrOmJpdHN0cmluZ1twcml2YXRlXS4KY29uc3QgY2VrMjpiaXRzdHJpbmdb cHJpdmF0ZV0uICgqIGFsdGVybmF0ZSBrZXkgcHJvdGVjdGVkIHdpdGggd2VhayBjcnlwdG8gKikK Cgp0YWJsZSByZWNpcGllbnRfdGFibGUoSUQsY2VydCkuCnRhYmxlIHJlY0VuY0tleV90YWJsZShJ RCxjZXJ0LGJpdHN0cmluZykuCnRhYmxlIFBTS19UQUJMRShQU0tJRCwgUFNLKS4KCgpmdW4gaWQy Yml0cyhJRCk6IGJpdHN0cmluZyBbdHlwZUNvbnZlcnRlcl0uCnJlZHVjIGZvcmFsbCB4OklEOyBi aXRzMmlkKGlkMmJpdHMoeCkpID0geC4KCmZ1biBwc2tpZDJiaXRzKFBTS0lEKTogYml0c3RyaW5n IFt0eXBlQ29udmVydGVyXS4KCgooKiBFdmVudHMgKikKZXZlbnQgU2VudENFSyhJRCxJRCwgSUQs IGJpdHN0cmluZykuCmV2ZW50IE9idGFpbmVkQ0VLKElELElELGJpdHN0cmluZykuCmV2ZW50IFJF Q0lQSUVOVEtERlNUUkVOR1RIKGJvb2wpLgpldmVudCBSRUNJUElFTlRDUllQVE9TVFJFTkdUSChi b29sKS4KZXZlbnQgU0VOREVSQ1JZUFRPU1RSRU5HVEgoYm9vbCkuCmV2ZW50IFNFTkRFUktERlNU UkVOR1RIKGJvb2wpLgoKCmZyZWUgaW86IGNoYW5uZWwuCmNvbnN0IEEsQixDLEQsRSxGLEgsSSxK LE0sUzpJRC4KY29uc3QgWkVSTzpiaXRzdHJpbmcuCgoKKCogTW9kZWwgc3VwcG9ydHMga2V5IHRy YW5zcG9ydCBhbGdvcml0aG1zICopCgpsZXQgU2VuZGVyKENFSzpiaXRzdHJpbmcscHNraWQ6UFNL SUQsIHNlbmRlcklEOklELCAgIHN0cm9uZ19jcnlwdG86Ym9vbCwgc3Ryb25nX2tkZjpib29sLGtl eW1nbXRhbGd0eXBlOmJpdHN0cmluZykgPSAoCiAgCiAgbmV3ICB4czpiaXRzdHJpbmc7ICAoKkRI IHByaXZhdGUga2V5IGZvciBzZW5kZXIqKQoKICBsZXQgU2VuZGVycHViID0gZGhfZXhwKEcsIHhz KSBpbgoKICAoKiBsZWFraW5nIHRoZSBvcmlnaW5hdG9yJ3MgcHJpdmF0ZSBrZXkgKikKICBvdXQo aW8sIHhzKTsKICAKICAoKiB0aGVzZSBhcmUgY29udmVydGVkIHRvIGFsZ29yaXRobSBpZHMgYW5k IHRoZSBlbmNyeXB0ZWQga2V5IGxlbmd0aCAqKQogIGxldCBrZGZpZCA9IGlmIHN0cm9uZ19rZGYg dGhlbiBIS0RGIGVsc2UgV0tERiBpbgogIGxldCBrZW5jaWQgPSBpZiBzdHJvbmdfY3J5cHRvIHRo ZW4gQUVTMjU2IGVsc2UgQUVTMTI4IGluCiAgbGV0IEwgPSBpZiBzdHJvbmdfY3J5cHRvIHRoZW4g bG9uZ2tleSBlbHNlIHNob3J0a2V5IGluCiAgCiAgKCogZ2V0IHRoZSBQU0sgYXNzaWduZWQgdG8g dGhlIHBza2lkICopCiAgZ2V0IFBTS19UQUJMRSg9cHNraWQscHNrKSBpbgoKICAoKiBMb29rIHVw IHRoZSB0d28gaW50ZW5kZWQgcmVjaXBpZW50cyAoYWx3YXlzIEEgYW5kIEIpICopCiAgZ2V0IHJl Y2lwaWVudF90YWJsZSg9QSxjZXJ0QSkgaW4KICBnZXQgcmVjaXBpZW50X3RhYmxlKD1CLGNlcnRC KSBpbgogIAogICgqIEltcGxlbWVudCB0aGUgbmV3IEFTTjEgc3RydWN0dXJlIGZvciBrZXkgZGVy aXZhdGlvbiBkZXNjcmliZWQgb24gcGFnZSA5ICopCiAgCiAgbGV0IHBza290aGVyaW5mbyA9IChw c2ssIGtleW1nbXRhbGd0eXBlLCBrZW5jaWQsIHBza2xlbiwga2RrbGVuKSBpbgoKICAoKiBrZXkg ZGVyaXZhdGlvbiBmb3IgZWFjaCByZWNpcGllbnQuIERlc2NyaWJlZCBvbiBwYWdlIDggKikKICAo KiBIS0RGKElLTSAsICggc2FsdCwgTCwgQ01TT1JJZm9yUFNLT3RoZXJJbmZvKSApKikKICBsZXQg c2FsdCA9IFpFUk8gaW4KICAoKiBJS00gaXMgdGhlIERIIHNoYXJlZCBzZWNyZXQgKikKICAoKiBS ZWNpcGllbnQgQSAqKQogIGxldCBHQSA9IGIyZWxlbWVudChjZXJ0X3B1YmtleShjZXJ0QSkpIGlu CiAgbGV0IGtlazFBID0gZTJiaXRzKGRoX2V4cChHQSwgeHMpKSBpbgoKICAoKiBoa2RmIGRlcml2 ZXMgdGhlIGtleSBlbmNyeXB0aW9uIGtleSAgKikKICBsZXQga2VrMkEgPSBpZiBzdHJvbmdfa2Rm IHRoZW4gaGtkZihiaXRzMmtleShrZWsxQSksIChzYWx0LCBMLHBza290aGVyaW5mbykpIGVsc2Ug aGtkZl93ZWFrKGJpdHMya2V5KGtlazFBKSkgaW4KICAKICAoKiBSZWNpcGllbnQgQiAqKQogIGxl dCBHQiA9IGIyZWxlbWVudChjZXJ0X3B1YmtleShjZXJ0QikpIGluCiAgbGV0IGtlazFCID0gZTJi aXRzKGRoX2V4cChHQiwgeHMpKSBpbgogIGxldCBrZWsyQiA9IGlmIHN0cm9uZ19rZGYgdGhlbiBo a2RmKGJpdHMya2V5KGtlazFCKSwgKHNhbHQsIEwscHNrb3RoZXJpbmZvKSkgZWxzZSBoa2RmX3dl YWsoYml0czJrZXkoa2VrMUIpKSBpbgoKICAoKiBXZSBjYW4gbm93IGJ1aWxkIHRoZSAgQ01TIGRh dGEgc3RydWN0dXJlIHJlY2lwaWVudCBpbmZvKikKICAoKiB2ZXJzaW9uKiwgcHNraWQsIG9yaWdp bmF0b3IsIHVrbSosIGtkZmFsZywga2V5ZW5jYWxnLCByZWNlbmNrZXlzICAqKQoKICBsZXQgZW5j Y2VrQSA9IGlmIHN0cm9uZ19jcnlwdG8gdGhlbiBzZW5jKGtlazJBLCBDRUspIGVsc2Ugc2VuY3dl YWsoa2VrMkEsQ0VLKSBpbgogIGxldCBlbmNjZWtCID0gaWYgc3Ryb25nX2NyeXB0byB0aGVuIHNl bmMoa2VrMkIsIENFSykgZWxzZSBzZW5jd2VhayhrZWsyQixDRUspIGluCiAgCiAgbGV0IG9yaWdp bmF0b3IgPSAoc2VuZGVySUQsIFNlbmRlcnB1YikgaW4KCiAgKCogdGhpcyBpcyBob3cgd2UgaW50 ZXJwcmV0IHRoZSByZWNpcGllbnQgZW5jcnlwdGVkIGtleSB2YWx1ZSBmb3Iga2V5IGFncmVlbWVu dCAqKQogIGxldCByZWNpcGllbnRlbmNrZXlzQSA9IChpZDJiaXRzKEEpLGNlcnQyYml0cyhjZXJ0 QSksZW5jY2VrQSAgKSBpbgogIGxldCByZWNpcGllbnRlbmNrZXlzQiA9IChpZDJiaXRzKEIpLGNl cnQyYml0cyhjZXJ0QiksZW5jY2VrQiAgKSBpbgogIAogIAogICBsZXQgS2V5QWdyZWVQU0tSZWNJ bmZvPSAoQ01TVmVyc2lvbl8wLCBwc2tpZCxvcmlnaW5hdG9yLGtkZmlkLCBrZW5jaWQsIHJlY2lw aWVudGVuY2tleXNBLHJlY2lwaWVudGVuY2tleXNCICApIGluCiAgCiAgb3V0KGlvLCBLZXlBZ3Jl ZVBTS1JlY0luZm8pOwoKICBldmVudCBTZW50Q0VLKHNlbmRlcklELCBBLEIsIENFSykKKS4KCmxl dCBzZW5kZXJzKENFSzpiaXRzdHJpbmcsIHBza2lkOlBTS0lELCBzZW5kZXJJRDpJRCwgc2NyeXB0 bzpib29sLCBza2RmOmJvb2wsa2V5bWdtdGFsZ3R5cGU6Yml0c3RyaW5nKSA9ICgKICAgIG5ldyBs dGs6IHByaXZrZXk7CiAgICAKICAgIFNlbmRlcihDRUssIHBza2lkLCBzZW5kZXJJRCwgc2NyeXB0 byxza2RmLCBrZXltZ210YWxndHlwZSkKKS4KCgoKCgoKbGV0IHJlY2lwaWVudHMocmVjaWQ6SUQs IHByaXZyOmJpdHN0cmluZywgS2NhOnB1YmtleSwga2V5bWdtdGFsZ3R5cGU6Yml0c3RyaW5nKSA9 ICgKCiAgCiAgICgqIGF0dGFja2VyIGNhbiBtb2RpZnkgc29tZSBvZiB0aGUgcmVjaXBpZW50J3Mg Y29uZmlndXJhdGlvbiB2YWx1ZXMgKikKICAgaW4oaW8sIHN0cm9uZ19jcnlwdG86Ym9vbCk7CiAg IGluKGlvLCBzdHJvbmdfa2RmOmJvb2wpOwoKICAgZXZlbnQgUkVDSVBJRU5UQ1JZUFRPU1RSRU5H VEgoc3Ryb25nX2NyeXB0byk7IAogICBldmVudCBSRUNJUElFTlRLREZTVFJFTkdUSChzdHJvbmdf a2RmKTsKICAKICAgaW4oaW8sICg9Q01TVmVyc2lvbl8wLHBza2lkOlBTS0lELG9yaWdpbmF0b3I6 Yml0c3RyaW5nLCBrZGZpZDpLREZJRCwga2VuY2lkOktFbmNJRCwgcmVjRW5jS2V5czE6Yml0c3Ry aW5nLCByZWNFbmNLZXlzMjpiaXRzdHJpbmcpKTsKCgogICBsZXQgKGlkYjE6Yml0c3RyaW5nLCBj ZXJ0YjE6Yml0c3RyaW5nLCBlbmNjZWsxOmJpdHN0cmluZykgPSByZWNFbmNLZXlzMSBpbgogICBs ZXQgaWQxID0gYml0czJpZChpZGIxKSBpbgogICBsZXQgY2VydDEgPSBiaXRzMmNlcnQoY2VydGIx KSBpbgoKCiAgIGxldCAoaWRiMjpiaXRzdHJpbmcsIGNlcnRiMjpiaXRzdHJpbmcsIGVuY2NlazI6 Yml0c3RyaW5nKSA9IHJlY0VuY0tleXMyIGluCiAgIGxldCBpZDIgPSBiaXRzMmlkKGlkYjIpIGlu CiAgIGxldCBjZXJ0MiA9IGJpdHMyY2VydChjZXJ0YjIpIGluCgogICAoKmRvIGEgYml0IG9mIGd5 bW5hc3RpY3MgdG8gZmluZCBvdXQgd2hpY2ggKGlmIGFueSApIGVuY3JlY2lwaWVudGtleXMgYXJl IGZvciBtZSAqKQogICAKICAgaW5zZXJ0IHJlY0VuY0tleV90YWJsZShpZDEsIGNlcnQxLCBlbmNj ZWsxKSA7CiAgIGluc2VydCByZWNFbmNLZXlfdGFibGUoaWQyLCBjZXJ0MiwgZW5jY2VrMikgOwog ICBnZXQgcmVjRW5jS2V5X3RhYmxlKD1yZWNpZCwgY2VydHJlYzpjZXJ0LCBlbmNjZWs6Yml0c3Ry aW5nKSBpbgogCiAgICgqIFZlcmlmeSB0aGUgcmVjZWl2ZWQgY2VydCwgd291bGQgdGhlIHJlY2lw aWVudCBub3QgdXNlIGhpcyBvd24gPyAqKQoKIGlmIHZlcmlmeV9jZXJ0KEtjYSwgcmVjaWQsIGNl cnRyZWMpIHRoZW4gKAogICAgCiAgKCpjaGVjayBpZiBjb25maWd1cmF0aW9uIG1ha2VzIHNlbnNl IHdpdGggd2hhdCBpcyBhY3R1YWxseSBzZW50LCB0aGlzIGlzIG92ZXJseSBjb21wbGljYXRlZCop CiAgaWYgKGtkZmlkID0gV0tERiAmJiBzdHJvbmdfa2RmIHx8IGtkZmlkID0gSEtERiAmJiBzdHJv bmdfa2RmID0gZmFsc2UpIHRoZW4KICAgMAogIGVsc2UoCiAgIGlmIChrZW5jaWQgPSBBRVMxMjgg JiYgc3Ryb25nX2NyeXB0byB8fCBrZW5jaWQgPSBBRVMyNTYgJiYgc3Ryb25nX2NyeXB0byA9IGZh bHNlKSB0aGVuCiAgICAwCiAgZWxzZSgKICAgICAKICAgKCogdXNlIHRoZSBwc2tpZCBzbyBnbyBn ZXQgdGhlIHBzayAqKSAgCiAgIGdldCBQU0tfVEFCTEUoPXBza2lkLCBwc2spIGluCiAgIAogICAo KiBleHRyYWN0IHRoZSBvcmlnaW5hdG9yIHB1YmxpYyBrZXlzICopCiAgIGxldCAoc2VuZGVyaWQ6 SUQsR3M6ZWxlbWVudCkgPSBvcmlnaW5hdG9yIGluCgogICAoCiAgCiAgICAgKCpleHRyYWN0IHRo ZSBzZW5kZXIgREggcHVibGljIGZyb20gdGhlIGNlcnRzIGFuZCBnZW5lcmF0ZSBzaGFyZWQgc2Vj cmV0KikKICAgIAogICAgIGxldCBrZWsxID0gZTJiaXRzKGRoX2V4cChHcyxwcml2cikpIGluCgog ICAgICgqIGtleSBkZXJpdmF0aW9uICopCiAgICAgbGV0IHBza290aGVyaW5mbyA9IChwc2ssa2V5 bWdtdGFsZ3R5cGUsIGtlbmNpZCwgcHNrbGVuLCBrZGtsZW4pIGluCiAgICAgbGV0IHNhbHQgPSBa RVJPIGluCiAgICAgKCpzZXQgdGhlIGxlbmd0aCBvZiB0aGUgb3V0cHV0IGtleWluZyBtYXRlcmlh bCBmb3Iga2V5IGRlcml2YXRpb24gYmFzZWQgb24ga2V5IGVuY3J5cHRpb24gYWxnbyopCiAgICAg bGV0IEwgPSBpZiBzdHJvbmdfY3J5cHRvIHRoZW4gbG9uZ2tleSBlbHNlIHNob3J0a2V5IGluICAK ICAgICBsZXQga2VrMiA9IGlmIHN0cm9uZ19rZGYgdGhlbiBoa2RmKGJpdHMya2V5KGtlazEpLCAo c2FsdCxMLHBza290aGVyaW5mbykpIGVsc2UgaGtkZl93ZWFrKGJpdHMya2V5KGtlazEpKSBpbgog ICAgIAogICAgICgqIGRlY3J5cHQgdGhlIGNlayBhbmQgY2hlY2sgaXQgaXMgY29ycmVjdCAqKQog ICAgIGxldCBwdXRhdGl2ZV9jZWsgPSBpZiBzdHJvbmdfY3J5cHRvIHRoZW4gc2RlYyhrZWsyLCBl bmNjZWspIGVsc2Ugc2RlY3dlYWsoZW5jY2VrKSBpbgogICAgIAogICAgIGlmIChwdXRhdGl2ZV9j ZWsgPSBjZWsgKSB0aGVuCiAgICAgICAgCiAgICAgICAgZXZlbnQgT2J0YWluZWRDRUsoc2VuZGVy aWQsIHJlY2lkLCBwdXRhdGl2ZV9jZWspCiAgICAgZWxzZQogICAgICAgIDAKICApICgqdmVyaWZ5 aW5nIHNlbmRlcidzIGNlcnQgKikKICkgKCp2ZXJpZnlpbmcgY29uZmlnKikKICkgKCp2ZXJpZnlp bmcgY29uZmlnKikKKSAoKiB2ZXJpZnlpbmcgcmVjZWl2ZXIncyBjZXJ0ICopCiAKKS4KCnNldCBp Z25vcmVUeXBlcyA9IGZhbHNlLgoKKCogZmlyc3QgcXVlcmllcyBhcmUgc2FuaXR5IGNoZWNrICop CgpxdWVyeSBzZW5kZXJpZDpJRCwgcmVjaWQxOklELCByZWNpZDI6SUQ7CmV2ZW50IChPYnRhaW5l ZENFSyhTLCByZWNpZDIsIGNlaykpID09PiBldmVudCAoU2VudENFSyhTLCByZWNpZDEscmVjaWQy LCBjZWspKSAuCgpxdWVyeSBzZW5kZXJpZDpJRCwgcmVjaWQxOklELCByZWNpZDI6SUQ7CmV2ZW50 IChPYnRhaW5lZENFSyhTLCByZWNpZDEsIGNlaykpID09PiBldmVudCAoU2VudENFSyhTLCByZWNp ZDEscmVjaWQyLCBjZWspKSAuCgooKnRoaXMgaXMgcmVhbGx5IHdoYXQgd2UgYXJlIGludGVyZXN0 ZWQgaW4gKikKCnF1ZXJ5IAogICBhdHRhY2tlcihjZWspID09PiBldmVudChTRU5ERVJDUllQVE9T VFJFTkdUSChmYWxzZSkpIHx8IGV2ZW50KFNFTkRFUktERlNUUkVOR1RIKGZhbHNlKSkuCgoKCgpw cm9jZXNzCiAgbmV3IGNhX2tleTogcHJpdmtleTsKICBuZXcgc2VuZGVyaWQ6SUQ7CiAgbmV3IHBz a2lkOlBTS0lEOwogIG5ldyBwc2s6UFNLOwogIG5ldyBwc2tpZDI6UFNLSUQ7CiAgbmV3IHBzazI6 UFNLOyAKICAKCiAgKCpwZXIgcmVjaXBpZW50IHByaXZhdGUga2V5cyBvZiB0aGUgREggY29udHJp YnV0aW9uIGFzc3VtZWQgdG8gYmUga25vd24gYnkgdGhlIFF1YW50dW0gYXJtZWQgYXR0YWNrZXIu IFRoZSB3YXkgdGhleSBhcmUgZGVmaW5lZCBoZXJlLCB0aGV5IHdpbGwgYmUga25vd24gYnkgYWxs IGxlZ2FsIHBhcnRpY2lwYW50cyopCgogICgqc2VuZGVycyopCiAgbmV3IHhDOmJpdHN0cmluZzsK ICBuZXcgeEI6Yml0c3RyaW5nOwogIG5ldyB4QTpiaXRzdHJpbmc7CgoKICAKICAoKmJ1aWxkIGNl cnRzIGNvbnRhaW5pbmcgc2lnbmVkIHZhbHVlcyBvZiB0aGUgcmVjaXBpZW50IERIIHB1YmxpYyBr ZXlzICopCiAgbGV0IENlcnRBID0gbWtDZXJ0KEEsIGUyYml0cyhkaF9leHAoRyx4QSApKSwgY2Ff a2V5KSBpbgogIGxldCBDZXJ0QiA9IG1rQ2VydChCLCBlMmJpdHMoZGhfZXhwKEcseEIgKSksIGNh X2tleSkgaW4KICBsZXQgQ2VydEMgPSBta0NlcnQoQywgZTJiaXRzKGRoX2V4cChHLHhDICkpLCBj YV9rZXkpIGluCgogIAogICgqIFB1Ymxpc2ggdGhlIGNlcnRpZmljYXRlcyAqKQogIG91dChpbyxD ZXJ0QSk7CiAgb3V0KGlvLENlcnRCKTsKICBvdXQoaW8sQ2VydEMpOwogCiAKICAKICAoKiBsZWFr IHRoZSBwZWVycycgcHJpdmF0ZSBrZXlzLCBjaGVhcCB3YXkgdG8gbWltaWNrIHRoZSBESCBwcml2 YXRlcyByZXZlYWxlZCB0aHJvdWdoIGEgcXVhbnR1bSBhdHRhY2suICopCiAgb3V0KGlvLHhBKTsK ICBvdXQoaW8seEIpOwogIG91dChpbyx4Qyk7CiAgCiAKIAogICgqIEJ1aWxkIHRoZSBQU0sgdGFi bGUgY29udGFpbmluZyB0d28gcHNrcyAqKQogIGluc2VydCBQU0tfVEFCTEUocHNraWQsIHBzayk7 CiAgaW5zZXJ0IFBTS19UQUJMRShwc2tpZDIsIHBzazIpOwoKICAoKkJ1aWxkIHRoZSByZWNpcGll bnQgdGFibGUgKikKICBpbnNlcnQgcmVjaXBpZW50X3RhYmxlKEEsQ2VydEEpOwogIGluc2VydCBy ZWNpcGllbnRfdGFibGUoQixDZXJ0Qik7CiAgaW5zZXJ0IHJlY2lwaWVudF90YWJsZShDLENlcnRD KTsKCiAgKCpXZSBjYW4gcGxheSB3aXRoIHRoZSBjb25maWd1cmF0aW9uIG9mIHNlbmRlciBTJ3Mg Y3J5cHRvIHN0cmVuZ3RoIHNldHRpbmdzLiAqKQogIAogCiAgKCogdGhpcyBzZXRzIHRoZSBlbmNy eXB0aW9uIGFsZ29yaXRobSwgcXVhbnR1bS12dWxuZXJhYmxlIEFFUzEyOCBvciBzdHJvbmcgQUVT MjU2ICopCiAgaW4oaW8sIHN0cm9uZ19jcnlwdG86Ym9vbCk7CiAgaW4oaW8sIHN0cm9uZ19rZGY6 Ym9vbCk7CiAKICBsZXQgd2Vha3NlbmRlcmNyeXB0byA9ICBpZiBzdHJvbmdfY3J5cHRvIHRoZW4g dHJ1ZSBlbHNlIGZhbHNlIGluCiAgZXZlbnQgU0VOREVSQ1JZUFRPU1RSRU5HVEgod2Vha3NlbmRl cmNyeXB0byk7IAogIGxldCB3ZWFrc2VuZGVya2RmID0gIGlmIHN0cm9uZ19rZGYgdGhlbiB0cnVl IGVsc2UgZmFsc2UgaW4KICBldmVudCBTRU5ERVJLREZTVFJFTkdUSCh3ZWFrc2VuZGVya2RmKTsK CiAgICgqdGhyZWUgcmVjaXBpZW50cyBzdGFydGVkIC4gQXR0YWNrZXIgY2FuIG1vZGlmeSB0aGVp ciBjcnlwdG8gY29uZmlndXJhdGlvbiAqKQoKICAgICAgIXJlY2lwaWVudHMoQSwgeEEsICBwayhj YV9rZXkpLCBrZXlBZ3JlZSkKICAgIHwgIXJlY2lwaWVudHMoQiwgeEIsICBwayhjYV9rZXkpLCBr ZXlBZ3JlZSkKICAgIHwgIXJlY2lwaWVudHMoQywgeEMsICBwayhjYV9rZXkpLCBrZXlBZ3JlZSkK CiAgICAoKiBTZW5kZXIgUyBzdGFydGVkLiBIYXMgQSBhbmQgQiBoYXJkd2lyZWQgYXMgcmVjaXBp ZW50cyAqKQogICAgKCogU2VuZGVyIFMgdXNlcyBzdHJvbmcgY3J5cHRvIGFuZCBzZW5kcyBjZWsg ICopCiAgICAoKiBOb3RlIC0gaGFyZHdpcmVkIGNlayAsIG5vdCBxdWl0ZSBjb3JyZWN0IGJ1dCBt YWtlcyBjaGVja3Mgb24gY2VrIGEgbGl0dGxlIGVhc2llciAqKQogICAgKCogVGhlcmUgaXMgYSB3 ZWFrIHNlbmRlciBGIGJ1dCBsdWNraWx5IGhlIGlzIHNlbmRpbmcgY2VrMiBhbmQgbm90IGNlayB3 aXRoIGhpcyB3ZWFrIGNyeXB0byAqKQogICAgKCogV2FzIHRyeWluZyB0byBzZWUgaWYgYSB2dWxu ZXJhYmxlIHNlbmRlciBjb3VsZCBiZSB3b3JrZWQgaW50byBhbiBhdHRhY2sgKikKCiAgICB8ICFz ZW5kZXJzKGNlaywgcHNraWQsICBTLCAgc3Ryb25nX2NyeXB0bywgc3Ryb25nX2tkZixrZXlBZ3Jl ZSkKCiAgICB8ICFzZW5kZXJzKGNlazIscHNraWQyLCBGLCAgZmFsc2UsIGZhbHNlLCBrZXlBZ3Jl ZSkKCg== --_002_ba3c46ac49d84bf892c04051f5fea3c5cybergcca_-- From nobody Mon May 27 09:48:39 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C255120169 for ; Mon, 27 May 2019 09:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.092 X-Spam-Level: X-Spam-Status: No, score=0.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWH3iMmEyjuf for ; Mon, 27 May 2019 09:48:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1D712015A for ; Mon, 27 May 2019 09:48:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id AFFA2300AA2 for ; Mon, 27 May 2019 12:29:15 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6gib_e00Av6W for ; Mon, 27 May 2019 12:29:13 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 387A930066E; Mon, 27 May 2019 12:29:13 -0400 (EDT) From: Russ Housley Message-Id: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3DEE9E57-EF12-469E-B83A-8B43C79C4B0E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 27 May 2019 12:48:30 -0400 In-Reply-To: Cc: Tim Hollebeek To: "spasm@ietf.org" References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 16:48:37 -0000 --Apple-Mail=_3DEE9E57-EF12-469E-B83A-8B43C79C4B0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hendrik: I see people speaking on both sides. So, I am asking a few questions to = see if there is enough support... 1) If this work is added to the charter, will you contribute to the = document? 2) If this work is added to the charter, will you review to the = document? 3) If this document is published as an RFC, will you implement it? Russ > On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik = wrote: >=20 > Hi Russ > =20 > Did you have the time to look into my mail below? > I would like to push this topic further forward. > =20 > Hendrik > =20 > Von: Brockhaus, Hendrik (CT RDA ITS SEA-DE)=20 > Gesendet: Montag, 20. Mai 2019 15:43 > An: Russ Housley > > Cc: Fries, Steffen (CT RDA ITS) >; spasm@ietf.org = > Betreff: AW: Proposed Re-Chartering Text for CMP updates and = lightweight profile (RE: Follow-up on lightweight CMP profile) > =20 > Hi Russ > =20 > We discussed my proposal on the mailing list. I feel there is quite = some support. > Tomas, Max and Martin supported the activity. There were some = questions and concerns from Panos, that I hopefully could clarify. > =20 > What is the next step? > =20 > Hendrik > =20 > Von: Spasm > Im = Auftrag von [ext] Brockhaus, Hendrik > Gesendet: Mittwoch, 8. Mai 2019 11:10 > An: spasm@ietf.org ; Russ Housley = > > Cc: Jim Schaad >; Fries, Steffen (CT RDA ITS) = > > Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and = lightweight profile (RE: Follow-up on lightweight CMP profile) > =20 > Hi Russ, all, > =20 > as discussed at IETF104 and on this list we would like to spend = further work on updating and profiling CMP focusing on industrial use = cases. > To get input, feedback and support from LAMPS we propose the following = charter text. > =20 > As certificate management gets increasingly important in industrial = environments, it needs to be tailored to the specific needs. CMP as = existing protocol offers a vast range of options. As it is already being = applied in industrial environments it needs to be enhanced to more = efficiently support of industrial use cases, crypto agility and specific = communication relations on the one hand and profiled to the necessary = functionality on the other hand to ease application and to better = facilitate interoperable implementation.=20 > =20 > =20 > Hendrik > =20 > Von: Russ Housley >=20= > Gesendet: Mittwoch, 8. Mai 2019 02:18 > An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) = > > Cc: spasm@ietf.org ; Jim Schaad = >; Fries, Steffen = (CT RDA ITS) > > Betreff: Re: [lamps] Follow-up on lightweight CMP profile > =20 > Hendrik: > =20 > The current re-charter is about two weeks away. You would need to = propose text for the charter on this list, and see if there are people = that will review and implement. > =20 > Russ > =20 > =20 >=20 > On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik = > = wrote: > =20 > Hi all >=20 > =20 >=20 > Referring to the Email thread 'Seeking guidance on proceeding with = question from IETF-104 presentation on lightweight CMP profile' and to = the outcome of the WG meeting, we want to summarize the current state of = the discussion. >=20 > The discussion we had with Jim motivate a split of the current draft = into a CMP Updates and a CMP Profile document. The update of CMP is = needed because we identified at least two point where a change to CMP is = needed: >=20 > - Change the type of encryptedCert from EncryptedValue to EncryptedKey = for ECC and post-quantum algorithm support >=20 > - Extend the RootCAUpdate announcement message to e request/response = message to enable requesting the update from the client side >=20 > The remaining points from the initial email were seen as profiling = topic and would therefore be handled in the CMP Profile document... >=20 > =20 >=20 > @Russ, how do you see the status of the current re-chartering process? = Would you support to add both, or at least the CMP Updates, activities = under the revised charter? >=20 > =20 >=20 > - Hendrik >=20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = > =20 > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_3DEE9E57-EF12-469E-B83A-8B43C79C4B0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hendrik:

I = see people speaking on both sides.  So, I am asking a few questions = to see if there is enough support...

1) If this work is added to the = charter, will you contribute to the document?

2) If this work is = added to the charter, will you review to the document?

3) If = this document is published as an RFC, will you implement it?

Russ


On May 27, 2019, at 9:03 AM, = Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> wrote:

Hi Russ
 
Did you = have the time to look into my mail below?
I would like to push this topic further = forward.
 
Hendrik
 
Von: Brockhaus, Hendrik (CT RDA = ITS SEA-DE) 
Gesendet: Montag, 20. Mai 2019 = 15:43
An: Russ Housley <housley@vigilsec.com>
Cc: Fries, Steffen (CT RDA ITS) = <steffen.fries@siemens.com>; spasm@ietf.org
Betreff: AW: Proposed Re-Chartering = Text for CMP updates and lightweight profile (RE: Follow-up on = lightweight CMP profile)
 
Hi Russ
 
We discussed my proposal on = the mailing list. I feel there is quite some support.
Tomas, Max and Martin supported the activity. = There were some questions and concerns from Panos, that I hopefully = could clarify.
 
What is the next step?
 
Hendrik
 
Von: Spasm <spasm-bounces@ietf.org> Im Auftrag = von [ext] = Brockhaus, Hendrik
Gesendet: Mittwoch, 8. Mai 2019 = 11:10
An: spasm@ietf.org; Russ Housley <housley@vigilsec.com>
Cc: Jim Schaad <ietf@augustcellars.com>; = Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: [lamps] Proposed = Re-Chartering Text for CMP updates and lightweight profile (RE: = Follow-up on lightweight CMP profile)
 
Hi Russ, all,
 
as discussed at IETF104 and = on this list we would like to spend further work on updating and = profiling CMP focusing on industrial use cases.
To get input, feedback and support from LAMPS = we propose the following charter text.
 
As = certificate management gets increasingly important in industrial = environments, it needs to be tailored to the specific needs. CMP as = existing protocol offers a vast range of options. As it is already being = applied in industrial environments it needs to be enhanced to more = efficiently support of industrial use cases, crypto agility and specific = communication relations on the one hand and profiled to the necessary = functionality on the other hand to ease application and to better = facilitate interoperable implementation. 
 
 
Hendrik
 
Von: Russ= Housley <housley@vigilsec.com> 
Gesendet: Mittwoch, 8. Mai 2019 = 02:18
An: Brockhaus, Hendrik (CT RDA = ITS SEA-DE) <hendrik.brockhaus@siemens.com>
Cc: spasm@ietf.org; Jim Schaad <ietf@augustcellars.com>; = Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamps] Follow-up on = lightweight CMP profile
 
Hendrik:
 
The current re-charter is about two weeks away.  You = would need to propose text for the charter on this list, and see if = there are people that will review and implement.
 
Russ
 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <hendrik.brockhaus@siemens.com> wrote:
 

Hi = all

 

Referring to the Email thread 'Seeking guidance on proceeding = with question from IETF-104 presentation on lightweight CMP profile' and = to the outcome of the WG meeting, we want to summarize the current state = of the discussion.

The = discussion we had with Jim motivate a split of the current draft into a = CMP Updates and a CMP Profile document. The update of CMP is needed = because we identified at least two point where a change to CMP is = needed:

- = Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support

- Extend the RootCAUpdate announcement message = to e request/response message to enable requesting the update from the = client side

The = remaining points from the initial email were seen as profiling topic and = would therefore be handled in the CMP Profile document...

 

@Russ, how do you see the = status of the current re-chartering process? Would you support to add = both, or at least the CMP Updates, activities under the revised = charter?

 

- = Hendrik

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

= --Apple-Mail=_3DEE9E57-EF12-469E-B83A-8B43C79C4B0E-- From nobody Mon May 27 11:24:02 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD104120077 for ; Mon, 27 May 2019 11:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=Ew/tguad; dkim=pass (1024-bit key) header.d=primekey.com header.b=Ew/tguad 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 a0NazBLHEIh4 for ; Mon, 27 May 2019 11:23:57 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF342120041 for ; Mon, 27 May 2019 11:23:56 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 329A66AA008D for ; Mon, 27 May 2019 20:15:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1558980915; bh=1ihZyLIcubimcDm+HocXW/FoSlwYWyzKTo9bBhL01Pc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Ew/tguadQUfDvokhtRNIkrjPaZHlaJfnKxEE7GGYuTr8lbj8DriPV4mrV4J1Vicug tCeu18QS6yv8VzvPT+Z447KOzAusKqKDjVW94ylKOziUIgXyhDatVRzHYhU6d7y/vW vWwaU1InG8Voaf71HtLkqhXV4fz7r2kBLk070+Mo= Received: from [192.168.1.215] (unknown [85.24.187.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 077FF6AA0088 for ; Mon, 27 May 2019 20:15:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1558980915; bh=1ihZyLIcubimcDm+HocXW/FoSlwYWyzKTo9bBhL01Pc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Ew/tguadQUfDvokhtRNIkrjPaZHlaJfnKxEE7GGYuTr8lbj8DriPV4mrV4J1Vicug tCeu18QS6yv8VzvPT+Z447KOzAusKqKDjVW94ylKOziUIgXyhDatVRzHYhU6d7y/vW vWwaU1InG8Voaf71HtLkqhXV4fz7r2kBLk070+Mo= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <74d90b58-b4f0-9688-1d9f-9f034c9cb24b@primekey.com> Date: Mon, 27 May 2019 20:15:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 18:24:00 -0000 Hi Russ, Is this question directed to the people who expressed support for the profile? If so: > 1) If this work is added to the charter, will you contribute to the > document? As in writing the actual text of the draft, possibly, but not planned. > 2) If this work is added to the charter, will you review to the document? Yes. I have reviewed the suggested draft already and given feedback. And will continue to do so. > 3) If this document is published as an RFC, will you implement it? Yes. Our software acts as CMP server in many industrial use-cases and we implement several CMP use cases (among them the 3GPP CMP profile). Therefore we will most likely support the new profile as well. Regards, Tomas On 2019-05-27 18:48, Russ Housley wrote: > Hendrik: > > I see people speaking on both sides.  So, I am asking a few questions to > see if there is enough support... > > 1) If this work is added to the charter, will you contribute to the > document? > > 2) If this work is added to the charter, will you review to the document? > > 3) If this document is published as an RFC, will you implement it? > > Russ > > >> On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik >> > >> wrote: >> >> Hi Russ >>   >> Did you have the time to look into my mail below? >> I would like to push this topic further forward. >>   >> Hendrik >>   >> *Von:* Brockhaus, Hendrik (CT RDA ITS SEA-DE)  >> *Gesendet:* Montag, 20. Mai 2019 15:43 >> *An:* Russ Housley > >> *Cc:* Fries, Steffen (CT RDA ITS) > >; spasm@ietf.org >> >> *Betreff:* AW: Proposed Re-Chartering Text for CMP updates and >> lightweight profile (RE: Follow-up on lightweight CMP profile) >>   >> Hi Russ >>   >> We discussed my proposal on the mailing list. I feel there is quite >> some support. >> Tomas, Max and Martin supported the activity. There were some >> questions and concerns from Panos, that I hopefully could clarify. >>   >> What is the next step? >>   >> Hendrik >>   >> *Von:* Spasm > > *Im Auftrag von *[ext] Brockhaus, Hendrik >> *Gesendet:* Mittwoch, 8. Mai 2019 11:10 >> *An:* spasm@ietf.org ; Russ Housley >> > >> *Cc:* Jim Schaad > >; Fries, Steffen (CT RDA ITS) >> > >> *Betreff:* [lamps] Proposed Re-Chartering Text for CMP updates and >> lightweight profile (RE: Follow-up on lightweight CMP profile) >>   >> Hi Russ, all, >>   >> as discussed at IETF104 and on this list we would like to spend >> further work on updating and profiling CMP focusing on industrial use >> cases. >> To get input, feedback and support from LAMPS we propose the following >> charter text. >>   >> As certificate management gets increasingly important in industrial >> environments, it needs to be tailored to the specific needs. CMP as >> existing protocol offers a vast range of options. As it is already >> being applied in industrial environments it needs to be enhanced to >> more efficiently support of industrial use cases, crypto agility and >> specific communication relations on the one hand and profiled to the >> necessary functionality on the other hand to ease application and to >> better facilitate interoperable implementation.  >>   >>   >> Hendrik >>   >> *Von:* Russ Housley >  >> *Gesendet:* Mittwoch, 8. Mai 2019 02:18 >> *An:* Brockhaus, Hendrik (CT RDA ITS SEA-DE) >> > >> *Cc:* spasm@ietf.org ; Jim Schaad >> >; Fries, >> Steffen (CT RDA ITS) > > >> *Betreff:* Re: [lamps] Follow-up on lightweight CMP profile >>   >> Hendrik: >>   >> The current re-charter is about two weeks away.  You would need to >> propose text for the charter on this list, and see if there are people >> that will review and implement. >>   >> Russ >>   >> >>   >> >> On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik >> > > wrote: >>   >> >> Hi all >> >>   >> >> Referring to the Email thread 'Seeking guidance on proceeding with >> question from IETF-104 presentation on lightweight CMP profile' >> and to the outcome of the WG meeting, we want to summarize the >> current state of the discussion. >> >> The discussion we had with Jim motivate a split of the current >> draft into a CMP Updates and a CMP Profile document. The update of >> CMP is needed because we identified at least two point where a >> change to CMP is needed: >> >> - Change the type of encryptedCert from EncryptedValue to >> EncryptedKey for ECC and post-quantum algorithm support >> >> - Extend the RootCAUpdate announcement message to e >> request/response message to enable requesting the update from the >> client side >> >> The remaining points from the initial email were seen as profiling >> topic and would therefore be handled in the CMP Profile document... >> >>   >> >> @Russ, how do you see the status of the current re-chartering >> process? Would you support to add both, or at least the CMP >> Updates, activities under the revised charter? >> >>   >> >> - Hendrik >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> >>   >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Mon May 27 15:37:02 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E562120019; Mon, 27 May 2019 15:36:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-rfc6844bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155899661364.650.12863963513956136622.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2019 15:36:53 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 22:36:54 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-rfc6844bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this helpful update! Section 2.2 I'm not entirely sure why we're going "backwards" from referencing STD13 to referencing RFCs 1034 and 1035 individually (in the definition of "Domain Name System"). Section 3 RelevantCAASet(domain): for domain is not ".": if CAA(domain) is not Empty: return CAA(domain) domain = Parent(domain) return Empty It would be nice to get an explicit note about whether this is intended to be pseudocode, Python code, etc.. Specifically, the "for domain is not '.'" syntax seems like it might be a more natural fit for a "while" construct. Section 4.3 issuewild properties MUST be ignored when processing a request for a Domain Name (that is, not a Wildcard Domain Name). I don't wish to revisit well-trodden ground (as I suspect this is), but note that the provided defitinions in Section 2.2 don't seem to exclude Wildcard Domain Names from being Domain Names, so that "that is" in the quoted text is not accurate. (In particular, note that the Wildcard Domain Name definition says that it is "a Domain Name consisting of [...]".) Section 4.5 The critical flag is intended to permit future versions of CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated Domain Names. It's not clear to me that the normative "MUST" is best, here. (Is anyone's behavior being constrained by this statement?) Section 5.1 An Issuer MUST NOT issue certificates if doing so would conflict with the Relevant RRSet, irrespective of whether the corresponding DNS records are signed. I recognize that this is already the security considerations section, but this requirement introduces its own security considerations, namely that in cases where CAA responses received by the Issuer can be spoofed, there is an opportunity for denial of service. Section 5.4 does not seem to address this additional consideration relating to spoofing. Section 5.5 perhaps touches on it, but merely talks about "introduction" of a CAA RR, which may or may not imply the possibility of spoofing to an arbitrary reader. Use of DNSSEC allows an Issuer to acquire and archive a proof that they were authorized to issue certificates for the Domain Name. Verification of such archives MAY be an audit requirement to verify CAA record processing compliance. Publication of such archives MAY be a transparency requirement to verify CAA record processing compliance. Neither of these "MAY"s seem to be constraining the parties involved in this specification, which makes me wonder if they are more appropriate as ordinary "may"s. Section 5.4 Data cached by third parties MUST NOT be relied on but MAY be used to support additional anti-spoofing or anti-suppression controls. Is "relied on" meant to imply "relied on as the sole source of DNS CAA information"? Section 8 Should the registration of the 'CAA' RRtype also be updated to refer to [this document]? From nobody Mon May 27 16:19:02 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 340AA120019; Mon, 27 May 2019 16:18:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-rfc6844bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155899913320.574.15070810245199939271.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2019 16:18:53 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 23:18:53 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-rfc6844bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [updating to note that some of the content from Section 5.7 of draft-ietf-acme-caa may be worth mentioning in the security considerations of this document] Thanks for this helpful update! Section 2.2 I'm not entirely sure why we're going "backwards" from referencing STD13 to referencing RFCs 1034 and 1035 individually (in the definition of "Domain Name System"). Section 3 RelevantCAASet(domain): for domain is not ".": if CAA(domain) is not Empty: return CAA(domain) domain = Parent(domain) return Empty It would be nice to get an explicit note about whether this is intended to be pseudocode, Python code, etc.. Specifically, the "for domain is not '.'" syntax seems like it might be a more natural fit for a "while" construct. Section 4.3 issuewild properties MUST be ignored when processing a request for a Domain Name (that is, not a Wildcard Domain Name). I don't wish to revisit well-trodden ground (as I suspect this is), but note that the provided defitinions in Section 2.2 don't seem to exclude Wildcard Domain Names from being Domain Names, so that "that is" in the quoted text is not accurate. (In particular, note that the Wildcard Domain Name definition says that it is "a Domain Name consisting of [...]".) Section 4.5 The critical flag is intended to permit future versions of CAA to introduce new semantics that MUST be understood for correct processing of the record, preventing conforming CAs that do not recognize the new semantics from issuing certificates for the indicated Domain Names. It's not clear to me that the normative "MUST" is best, here. (Is anyone's behavior being constrained by this statement?) Section 5.1 An Issuer MUST NOT issue certificates if doing so would conflict with the Relevant RRSet, irrespective of whether the corresponding DNS records are signed. I recognize that this is already the security considerations section, but this requirement introduces its own security considerations, namely that in cases where CAA responses received by the Issuer can be spoofed, there is an opportunity for denial of service. Section 5.4 does not seem to address this additional consideration relating to spoofing. Section 5.5 perhaps touches on it, but merely talks about "introduction" of a CAA RR, which may or may not imply the possibility of spoofing to an arbitrary reader. Use of DNSSEC allows an Issuer to acquire and archive a proof that they were authorized to issue certificates for the Domain Name. Verification of such archives MAY be an audit requirement to verify CAA record processing compliance. Publication of such archives MAY be a transparency requirement to verify CAA record processing compliance. Neither of these "MAY"s seem to be constraining the parties involved in this specification, which makes me wonder if they are more appropriate as ordinary "may"s. Section 5.4 Data cached by third parties MUST NOT be relied on but MAY be used to support additional anti-spoofing or anti-suppression controls. Is "relied on" meant to imply "relied on as the sole source of DNS CAA information"? Section 8 Should the registration of the 'CAA' RRtype also be updated to refer to [this document]? From nobody Tue May 28 02:26:37 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C18612003E; Tue, 28 May 2019 02:26:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-lamps-rfc6844bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155903558962.25769.15348770094720924209.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2019 02:26:29 -0700 Archived-At: Subject: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 09:26:30 -0000 Barry Leiba has entered the following ballot position for draft-ietf-lamps-rfc6844bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- — Section 4.1 — Tag Length: A single octet containing an unsigned integer specifying the tag length in octets. The tag length MUST be at least 1 and SHOULD be no more than 15. What happens if it’s more than 15? What’s the interoperability issue, and how would an implementor decide what to do with this requirement? Tags MAY contain US-ASCII characters 'a' through 'z', 'A' through 'Z', and the numbers 0 through 9. Tags SHOULD NOT contain any other characters. Matching of tags is case insensitive. Why “SHOULD NOT”, rather than “MUST NOT”? Why might my implementation need to use other characters, and what are the interoperability consequences of doing so? — Section 4.1.1 — Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower case. Make it “non-zero-length”. -- Section 4.4 — The iodef Property Tag takes a URL as its Property Value. The URL scheme type determines the method used for reporting: I presume that *only* the specified schemes (mailto, http, https) are allowed; it would help to be explicit about that, lest someone get ideas to use sip or some such. — Section 5.6 — In practice, such an attack would be of minimal effect since any competent competitor that found itself unable to issue certificates due to lack of support for a Property marked critical SHOULD investigate the cause and report the reason to the customer. The customer will thus discover that they had been deceived. This doesn’t strike me as a BCP 14 “SHOULD”, but a normal English “should”. From nobody Tue May 28 02:48:39 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52512120058; Tue, 28 May 2019 02:48:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <155903691732.25794.18265731041364134208.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2019 02:48:37 -0700 Archived-At: Subject: [lamps] Barry Leiba's Yes on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 09:48:37 -0000 Barry Leiba has entered the following ballot position for draft-ietf-lamps-hash-of-root-key-cert-extn-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Useful stuff and well written; thanks very much. I, too, wonder why this isn't Proposed Standard (and why the shepherd writeup doesn't explain that). From nobody Tue May 28 04:00:12 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C496120143 for ; Tue, 28 May 2019 04:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1iUFs9UvnAf for ; Tue, 28 May 2019 04:00:06 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70110.outbound.protection.outlook.com [40.107.7.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB6212012C for ; Tue, 28 May 2019 04:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IJIScnqHZMm6Ucr3PHvMGO1RbsG0bALFqWifYb/hZVU=; b=lVq9isAF9xgO/btcQgBU+som3yqq6vLS1qkBM8ISjPLFmYsgIKaNzN/kpXX3eDIer9zC/EL/IiL2JJaw7CdYh4hjEkFhv32m1pxRV412CdTFhz5Ihi6DuIcS+WjttCnN8sRG3dU8+N32zOHlbESpyxrKlxrXMlbjJBL8IV8dG84= Received: from HE1PR0701MB2444.eurprd07.prod.outlook.com (10.168.130.8) by HE1PR0701MB3004.eurprd07.prod.outlook.com (10.168.93.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.13; Tue, 28 May 2019 11:00:03 +0000 Received: from HE1PR0701MB2444.eurprd07.prod.outlook.com ([fe80::4457:ee7d:f295:6ceb]) by HE1PR0701MB2444.eurprd07.prod.outlook.com ([fe80::4457:ee7d:f295:6ceb%9]) with mapi id 15.20.1943.015; Tue, 28 May 2019 11:00:03 +0000 From: "Peylo, Martin (Nokia - FI/Espoo)" To: Russ Housley , "spasm@ietf.org" CC: Tim Hollebeek Thread-Topic: [lamps] Support for working on the lightweight CMP profile Thread-Index: AQHVFKwNiB+RnXVsz0qy43JaaEsToaaAUuoA Date: Tue, 28 May 2019 11:00:02 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> In-Reply-To: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=martin.peylo@nokia.com; x-originating-ip: [131.228.2.0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06c41ffb-2218-4c38-05e3-08d6e35ba2b9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:HE1PR0701MB3004; x-ms-traffictypediagnostic: HE1PR0701MB3004: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(366004)(396003)(136003)(189003)(199004)(53754006)(52314003)(4326008)(66446008)(53936002)(236005)(561944003)(966005)(54896002)(9686003)(81156014)(81166006)(3846002)(71190400001)(52536014)(99286004)(7736002)(6246003)(5660300002)(8936002)(71200400001)(186003)(6116002)(790700001)(6306002)(74316002)(25786009)(2906002)(8676002)(229853002)(64756008)(86362001)(256004)(486006)(14454004)(102836004)(7696005)(6506007)(53546011)(476003)(11346002)(446003)(76176011)(316002)(73956011)(66946007)(66476007)(110136005)(2501003)(14444005)(66556008)(6436002)(68736007)(76116006)(606006)(55016002)(26005)(33656002)(508600001)(66066001)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3004; H:HE1PR0701MB2444.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: E4IgHZvu50XpclMjixsJl+vU1+BAU5wqdcSn9YJo1/m9EwraUKdnPf2OnAA/OVaKOl+HmspZUM7xFVuT4AWQHZj/oJ4h8W1MmgmHTStU1FW6b8g+DogfabgkcoFPjxqdBEkVHWdqqn1rgI23jyeLSfpFYGfKInefXFigVK+wg0yeK+B+CER8BmC8HDQ3QT6witHMQ23hi2AhG9eAjWNhexglmkwb0kPVc7UJXN2lsZLvJBd9nd565Zg4l51BwZ5PUlg33H6VQIz4X8OKF32M/dj2dusPfqP7TzpMuriFmChsugteD/pHuzD4HXS9fs5DK5+gAIKJevktu2KTAk35TeS+846ApVMVMLOIyetnyldKoqmA09GlI99o+1ryoxu3Tu5GM1OXXHpI3Xmny8/hFRFdF4tdcChaWSWpJs7I4Fw= Content-Type: multipart/alternative; boundary="_000_HE1PR0701MB2444E1198A626D9FF28292829B1E0HE1PR0701MB2444_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06c41ffb-2218-4c38-05e3-08d6e35ba2b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2019 11:00:02.9976 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: martin.peylo@nokia.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3004 Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 11:00:10 -0000 --_000_HE1PR0701MB2444E1198A626D9FF28292829B1E0HE1PR0701MB2444_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, 1. If this work is added to the charter, will you contribute to the docu= ment? Yes, mainly by means of review, I am planning to only contribute longer chu= nks of text if it becomes obvious during review that it is beneficial if I = would create an explicit text proposal. 1. If this work is added to the charter, will you review to the document= ? Yes. Based on my 10-year experience being involved with implementing the Op= ensSSL CMP client, which is amongst others predominantly used in the 3GPP t= elco-domain. 1. If this document is published as an RFC, will you implement it? Yes, it can be expected that the OpenSSL-based CMP client library/applicati= on [1] will very likely support the profiles defined in the process. The ap= plication will be useable as compliant RA on the CLI, while the FOSS-code m= ight not support an RA networking interface towards EEs. The library will a= lso be suitable to implement a compliant RA, networked towards the EE, with= reasonable effort if the integrated into an (e.g.) HTTP-server framework. = It is expected that this code gets introduced into an upcoming OpenSSL vers= ion, currently review activities are ongoing. The Mbed(tm) TLS-based simple CMP client library/application proof-of-conce= pt I have put together [2] might be eventually updated (if needed) to suppo= rt a simple IoT profile, while I cannot commit priority for that on my side= at this time. Anyway, it's FOSS and I will happily support anybody who is = interested to drive this forward. It should be noted that most of the profiling in existing mature CMP server= /client implementations will be probably be possible by already existing co= nfiguration means. I only expect need for polishing activity of smaller asp= ects in existing implementations, to remove so far existing difficulties fo= r certain use cases (e.g. if the client is an RA), or where new mandatory a= lgorithms are introduced (e.g. as SHA1 needs to get deprecated) - that shou= ld be very reasonable development effort. [1] https://github.com/mpeylo/cmpossl [2] https://github.com/nokia/CMPclient-embedded Cheers, Martin From: Spasm On Behalf Of Russ Housley Sent: Monday, May 27, 2019 7:49 PM To: spasm@ietf.org Cc: Tim Hollebeek Subject: [lamps] Support for working on the lightweight CMP profile Hendrik: I see people speaking on both sides. So, I am asking a few questions to se= e if there is enough support... 1) If this work is added to the charter, will you contribute to the documen= t? 2) If this work is added to the charter, will you review to the document? 3) If this document is published as an RFC, will you implement it? Russ On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik > wrote: Hi Russ Did you have the time to look into my mail below? I would like to push this topic further forward. Hendrik Von: Brockhaus, Hendrik (CT RDA ITS SEA-DE) Gesendet: Montag, 20. Mai 2019 15:43 An: Russ Housley > Cc: Fries, Steffen (CT RDA ITS) >; spasm@ietf.org Betreff: AW: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Russ We discussed my proposal on the mailing list. I feel there is quite some su= pport. Tomas, Max and Martin supported the activity. There were some questions and= concerns from Panos, that I hopefully could clarify. What is the next step? Hendrik Von: Spasm > Im Auftr= ag von [ext] Brockhaus, Hendrik Gesendet: Mittwoch, 8. Mai 2019 11:10 An: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; Fri= es, Steffen (CT RDA ITS) > Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_HE1PR0701MB2444E1198A626D9FF28292829B1E0HE1PR0701MB2444_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ,<= o:p>

&nbs= p;

  1. If this work is added to the charter, will you c= ontribute to the document?

 

Yes, mainly by means of review,= I am planning to only contribute longer chunks of text if it becomes obvio= us during review that it is beneficial if I would create an explicit text p= roposal.

 

  1. If this work is added to the charter, will you r= eview to the document?

 

Yes. Based on my 10-year experi= ence being involved with implementing the OpensSSL CMP client, which is amo= ngst others predominantly used in the 3GPP telco-domain.

  1. If this document is published as an RFC, will yo= u implement it?

 

Yes, it can be expected that th= e OpenSSL-based CMP client library/application [1] will very likely support= the profiles defined in the process. The application will be useable as co= mpliant RA on the CLI, while the FOSS-code might not support an RA networking interface towards EEs. The library will= also be suitable to implement a compliant RA, networked towards the EE, wi= th reasonable effort if the integrated into an (e.g.) HTTP-server framework= . It is expected that this code gets introduced into an upcoming OpenSSL version, currently review activit= ies are ongoing.

 

The Mbed™ TLS-based simple CMP client library/application proof-of-concept I h= ave put together [2] might be eventually updated (if needed) to support a s= imple IoT profile, while I cannot commit priority for that on my side at th= is time. Anyway, it’s FOSS and I will happily support anybody who is interested to drive this forward.

 

It should be noted that most of= the profiling in existing mature CMP server/client implementations will be= probably be possible by already existing configuration means. I only expec= t need for polishing activity of smaller aspects in existing implementations, to remove so far existing difficultie= s for certain use cases (e.g. if the client is an RA), or where new mandato= ry algorithms are introduced (e.g. as SHA1 needs to get deprecated) –= that should be very reasonable development effort.

 

[1] https://github.com/mpeylo/cmpossl

[2] https://github.com/nokia/CMPclient-embedded

 

Cheers,

Martin

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Monday, May 27, 2019 7:49 PM
To: spasm@ietf.org
Cc: Tim Hollebeek <tim.hollebeek@digicert.com>
Subject: [lamps] Support for working on the lightweight CMP profile<= o:p>

 

Hendrik:

 

I see people speaking on both sides.  So, I am = asking a few questions to see if there is enough support...

 

1) If this work is added to the charter, will you co= ntribute to the document?

 

2) If this work is added to the charter, will you re= view to the document?

 

3) If this document is published as an RFC, will you= implement it?

 

Russ

 



On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik <= hendrik.brockhaus@siemens.= com> wrote:

 

Hi Russ

 

Did you have the time to look i= nto my mail below?

I would like to push this topic= further forward.

 

Hendrik

 

Von:&nb= sp;Brockhaus, Hendrik (CT RDA ITS SEA-DE) 
Gesendet: Montag, = 20. Mai 2019 15:43
An: Russ Housley &= lt;hou= sley@vigilsec.com>
Cc: Fries, Steffen= (CT RDA ITS) <steffen.fries@siemens.com>; spasm@ietf.org
Betreff: AW: Propo= sed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-= up on lightweight CMP profile)

 

Hi Russ

 

We discussed my proposal on the= mailing list. I feel there is quite some support.

Tomas, Max and Martin supported= the activity. There were some questions and concerns from Panos, that I ho= pefully could clarify.

 

What is the next step?

 

Hendrik

 

Von:&nb= sp;Spasm <spasm-bounces@ietf.org> Im Auftrag von [ext] Brockhaus, Hendrik
Gesendet: Mittwoch= , 8. Mai 2019 11:10
An: spasm@ietf.org;= Russ Housley <housley@vigilsec.com>
Cc: Jim Schaad <= ;iet= f@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.= fries@siemens.com>
Betreff: [lamps] P= roposed Re-Chartering Text for CMP updates and lightweight profile (RE: Fol= low-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on = this list we would like to spend further work on updating and profiling CMP= focusing on industrial use cases.

To get input, feedback and supp= ort from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von:&nb= sp;Russ Housley <housley@vigilsec.com> 
Gesendet: Mittwoch= , 8. Mai 2019 02:18
An: Brockhaus, Hen= drik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>= ;
Cc: spasm@ietf.org;= Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamp= s] Follow-up on lightweight CMP profile

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.com> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ...

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

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

 

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

 

--_000_HE1PR0701MB2444E1198A626D9FF28292829B1E0HE1PR0701MB2444_-- From nobody Tue May 28 06:18:23 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6523C120152 for ; Tue, 28 May 2019 06:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-dmu0_mrevu for ; Tue, 28 May 2019 06:18:18 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150052.outbound.protection.outlook.com [40.107.15.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13D7D120150 for ; Tue, 28 May 2019 06:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector2-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=shkbcRi6XvAScEIvHh8Sa3pAXWjxEnFd038jdsCoj34=; b=JN0DbYqxsACfquvnHPnw6jB4gXggGLvBLXggT0UA4wxcbpeXX7EzAMFmZ/ptrq6DoFRjcsr1eC+0ZCajZTTTSR94e2vMNCY0DX6hdndZEIG2rVr9gIYHwiP4WnkJ0BtPFEv46//cz0oisHlRRaT3m9NF1JdxOL0NoyVuXN3RM6Q= Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM (20.177.110.224) by AM0PR10MB2498.EURPRD10.PROD.OUTLOOK.COM (20.177.108.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.16; Tue, 28 May 2019 13:18:15 +0000 Received: from AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4]) by AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM ([fe80::5cae:fe46:2088:49e4%7]) with mapi id 15.20.1922.021; Tue, 28 May 2019 13:18:15 +0000 From: "Brockhaus, Hendrik" To: Russ Housley , "spasm@ietf.org" CC: Tim Hollebeek Thread-Topic: [lamps] Support for working on the lightweight CMP profile Thread-Index: AQHVFKwRAY7BM8QHd068AUQyGlLtFqaAQiGQ Date: Tue, 28 May 2019 13:18:15 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> In-Reply-To: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: spf=none (sender IP is ) smtp.mailfrom=hendrik.brockhaus@siemens.com; x-originating-ip: [80.146.228.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 94fd9f86-be11-4283-061c-08d6e36ef144 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM0PR10MB2498; x-ms-traffictypediagnostic: AM0PR10MB2498: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(136003)(39860400002)(346002)(396003)(199004)(189003)(53754006)(6506007)(5660300002)(53546011)(64756008)(66556008)(66476007)(102836004)(52536014)(66946007)(73956011)(2501003)(76176011)(66446008)(76116006)(55016002)(66066001)(9686003)(486006)(86362001)(236005)(99286004)(6306002)(54896002)(11346002)(446003)(71190400001)(71200400001)(81156014)(4326008)(476003)(81166006)(14444005)(478600001)(25786009)(2906002)(8676002)(561944003)(14454004)(110136005)(33656002)(316002)(74316002)(606006)(7696005)(6436002)(53936002)(3846002)(790700001)(6116002)(966005)(256004)(68736007)(26005)(7736002)(19627235002)(186003)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR10MB2498; H:AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: siemens.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8LnQjO7NsrRCuQuEWdKINtU0b8pjB7hWHwk9i36s5Cl41oSAYM6yYPkRIYKQNkFbTcEtHpqDT3+F1gEP8Zr5Aigo/b5nVNWesi2W4r1GcGqKDRu/oZ0GhETZRwHCAE4IfFrA/kMZKyd9LUTMmb2lMTyCZ4lpa8UyZOAV0MB/QiHNmahJWfLKyEAqjiAU+bKcmZyytZLAoJjqCOlNFBmNzFsdyIV15EdVtCUaKNz3Bs67FrRACtaejXIlHGVr5xZeWcgghTJ9gUgtxzczVZZXmwzWd7zFV9i+2P5OlAyCzRgXfFLwJVEVh3eQ7b1+or6uLqgmjv4OpYXhGgha94RApGLEKZubztEYGwX0tX4GBUPznjQktbPgE6ES6GhihitNJCvddhL9MC/kaSDT99OG3Ni6SCXPV1BYMUoQHZeTiKw= Content-Type: multipart/alternative; boundary="_000_AM0PR10MB24026177B31292D7C62D2B8DFE1E0AM0PR10MB2402EURP_" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-Network-Message-Id: 94fd9f86-be11-4283-061c-08d6e36ef144 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2019 13:18:15.1749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hendrik.brockhaus@siemens.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2498 Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 13:18:22 -0000 --_000_AM0PR10MB24026177B31292D7C62D2B8DFE1E0AM0PR10MB2402EURP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Russ, thank you for these questions and thanks to Tomas and Martin for their stat= ements. I know about some other companies that are interested in this work e.g. fro= m the rail automation industry. Hendrik Hendrik: I see people speaking on both sides. So, I am asking a few questions to se= e if there is enough support... 1) If this work is added to the charter, will you contribute to the documen= t? [Bro] Yes, I am willing to be the editor of these documents, but I am also= happy to be co-author if there is someone else to be editor of one of the = documents. Jim offered to be the editor of the CMP Updates document, but th= is was in April and I did not hear from him since then. 2) If this work is added to the charter, will you review to the document? [Bro] Yes 3) If this document is published as an RFC, will you implement it? [Bro] Yes. We already implement the profile in C based on OpenSSL and MbedT= LS (see also projects listed by Martin which we use and also actively contr= ibute to) and in Java and C# based on Bouncy Castle. Russ On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik > wrote: Hi Russ Did you have the time to look into my mail below? I would like to push this topic further forward. Hendrik Von: Brockhaus, Hendrik (CT RDA ITS SEA-DE) Gesendet: Montag, 20. Mai 2019 15:43 An: Russ Housley > Cc: Fries, Steffen (CT RDA ITS) >; spasm@ietf.org Betreff: AW: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Russ We discussed my proposal on the mailing list. I feel there is quite some su= pport. Tomas, Max and Martin supported the activity. There were some questions and= concerns from Panos, that I hopefully could clarify. What is the next step? Hendrik Von: Spasm > Im Auftr= ag von [ext] Brockhaus, Hendrik Gesendet: Mittwoch, 8. Mai 2019 11:10 An: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; Fri= es, Steffen (CT RDA ITS) > Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_AM0PR10MB24026177B31292D7C62D2B8DFE1E0AM0PR10MB2402EURP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Russ,<= o:p>

&nbs= p;

thank you for these questions and thanks to Tomas and Martin for thei= r statements.

I know about some other companies that are interested in this work e.= g. from the rail automation industry.

 

Hendrik

 

Hendrik:

 

I see people speaking on both sides.  So, I am = asking a few questions to see if there is enough support...

 

1) If this work is added to the= charter, will you contribute to the document?

[Bro]  Yes, I am wil= ling to be the editor of these documents, but I am also happy to be co-auth= or if there is someone else to be editor of one of the documents. Jim offered to be the editor of the CMP Updates docume= nt, but this was in April and I did not hear from him since then.

 

2) If this work is added to the charter, will you re= view to the document?

[Bro] Yes

 

3) If this document is published as an RFC, will you= implement it?

[Bro] Yes. We already imp= lement the profile in C based on OpenSSL and MbedTLS (see also projects lis= ted by Martin which we use and also actively contribute to) and in Java and= C# based on Bouncy Castle.<= /span>

 

Russ

 



On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik <= hendrik.brockhaus@siemens.= com> wrote:

 

Hi Russ

 

Did you have the time to look i= nto my mail below?

I would like to push this topic= further forward.

 

Hendrik

 

Von:&nb= sp;Brockhaus, Hendrik (CT RDA ITS SEA-DE) 
Gesendet: Montag, = 20. Mai 2019 15:43
An: Russ Housley &= lt;hou= sley@vigilsec.com>
Cc: Fries, Steffen= (CT RDA ITS) <steffen.fries@siemens.com>; spasm@ietf.org
Betreff: AW: Propo= sed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-= up on lightweight CMP profile)

 

Hi Russ

 

We discussed my proposal on the= mailing list. I feel there is quite some support.

Tomas, Max and Martin supported= the activity. There were some questions and concerns from Panos, that I ho= pefully could clarify.

 

What is the next step?

 

Hendrik

 

Von:&nb= sp;Spasm <spasm-bounces@ietf.org> Im Auftrag von [ext] Brockhaus, Hendrik
Gesendet: Mittwoch= , 8. Mai 2019 11:10
An: spasm@ietf.org;= Russ Housley <housley@vigilsec.com>
Cc: Jim Schaad <= ;iet= f@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.= fries@siemens.com>
Betreff: [lamps] P= roposed Re-Chartering Text for CMP updates and lightweight profile (RE: Fol= low-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on = this list we would like to spend further work on updating and profiling CMP= focusing on industrial use cases.

To get input, feedback and supp= ort from LAMPS we propose the following charter text.

 

As certificate management gets increasingly important in ind= ustrial environments, it needs to be tailored to the specific needs. CMP as= existing protocol offers a vast range of options. As it is already being applied in industrial environments it needs to be e= nhanced to more efficiently support of industrial use cases, crypto agility= and specific communication relations on the one hand and profiled to the n= ecessary functionality on the other hand to ease application and to better facilitate interoperable implementa= tion. 

 

 

Hendrik

 

Von:&nb= sp;Russ Housley <housley@vigilsec.com> 
Gesendet: Mittwoch= , 8. Mai 2019 02:18
An: Brockhaus, Hen= drik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>= ;
Cc: spasm@ietf.org;= Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamp= s] Follow-up on lightweight CMP profile

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.com> wrote:

 

Hi all

 

Referring to the Email thread 'Seeking guidance on proce= eding with question from IETF-104 presentation on lightweight CMP profile' = and to the outcome of the WG meeting, we want to summarize the current state of the discussion.

The discussion we had with Jim motivate a split of the c= urrent draft into a CMP Updates and a CMP Profile document. The update of C= MP is needed because we identified at least two point where a change to CMP is needed:

- Change the type of encryptedCert from EncryptedValue t= o EncryptedKey for ECC and post-quantum algorithm support=

- Extend the RootCAUpdate announcement message to e requ= est/response message to enable requesting the update from the client side

The remaining points from the initial email were seen as= profiling topic and would therefore be handled in the CMP Profile document= ...

 

@Russ, how do you see the status of the current re-chart= ering process? Would you support to add both, or at least the CMP Updates, = activities under the revised charter?

 

- Hendrik

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

 

_______________________________________________ Spasm mailing list
Spasm@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/spasm

 

--_000_AM0PR10MB24026177B31292D7C62D2B8DFE1E0AM0PR10MB2402EURP_-- From nobody Tue May 28 07:55:41 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40920120229 for ; Tue, 28 May 2019 07:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Y2kMU9qv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Z9tc8XSc 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 NXzDAfps4jBG for ; Tue, 28 May 2019 07:55:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB11120221 for ; Tue, 28 May 2019 07:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24310; q=dns/txt; s=iport; t=1559055335; x=1560264935; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PVNAlZMC1JwmCShNvtora8fYhTYIKSLU66DFFu9hReU=; b=Y2kMU9qv/d7DlNjUM/f64wy7CTTcyicUDrscWEmt8bTYVTzcmRk7YyL+ 94+k3C3h5p+Lg3zr8V+7JQMooZb528A4Ue6+9RXOut6hdwEcHycjF97Qn NtxKAcPor+uFLVVJpIVv6vVa41SGUIKV4XNOwSwl8OK++G4TSNK1qQ1AB Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AFFe/GR9zix+jp/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaGAEjjJfjjRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADgSu1c/4oNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgQ4vJCwDaVUgBAsoCodQA459gleXK4E?= =?us-ascii?q?uFIEQA1QJAQEBDAEBGAEJCwIBAYEFXYJeAoJjIzUIDgEDAQEEAQECAQRtHAy?= =?us-ascii?q?FSgEBAQEDAQEQGxMBASwEBwEPAgEIEQQBASEHBycLFAkIAgQBDQUIGoJ7BAK?= =?us-ascii?q?BHU0DHQECDJ4bAoE4iF+CIIJ5AQEFgTIBg0gDFYIPAwaBNAGKD4FDF4FAP4E?= =?us-ascii?q?RRoIeLj6CYQEBAhiBCwkBEgEhKwmDBoIEIotFESSGdZVoCQKCDYY0jHyCH5Q?= =?us-ascii?q?qjG6BKJRQAgQCBAUCDgEBBYFRAzMNWXFwFTuCbBOBWCQMF4NNhRSFP3IBAQE?= =?us-ascii?q?BgSWLKoEiATFvAQE?= X-IronPort-AV: E=Sophos;i="5.60,523,1549929600"; d="scan'208,217";a="569045423" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 May 2019 14:55:33 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x4SEtXG7000434 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 May 2019 14:55:33 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 May 2019 09:55:32 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 28 May 2019 09:55:32 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 28 May 2019 10:55:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Wi0NNpeTV7XF28eBv0ElrsknGkMUd40Wb+Feypz1Bv0=; b=Z9tc8XSctsIwKZMUvtWfDsUwxI2K8XN5+0ncM4XjnQlVMKsitQh3P4fj0u69R7qaylqxRn1gk5xDsOWfpOey7qeqHp/ldDEpen+74MeL2Bpjb/jujx+MwBaM3h5dusgYsSs8VIyq9ZEOrL2V9kJTRk0AWIFPGNWKdVwNsd0EChc= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2563.namprd11.prod.outlook.com (52.135.244.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.18; Tue, 28 May 2019 14:55:29 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5463:bad7:8321:766e]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::5463:bad7:8321:766e%6]) with mapi id 15.20.1922.021; Tue, 28 May 2019 14:55:29 +0000 From: "Panos Kampanakis (pkampana)" To: Russ Housley , "spasm@ietf.org" CC: Tim Hollebeek Thread-Topic: [lamps] Support for working on the lightweight CMP profile Thread-Index: AQHVFKwjCgg4zQvDK0+wrj7gz31+X6aAncgg Date: Tue, 28 May 2019 14:55:29 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> In-Reply-To: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90ab8776-ee73-417e-489b-08d6e37c869c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2563; x-ms-traffictypediagnostic: BN7PR11MB2563: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(396003)(136003)(366004)(199004)(189003)(53754006)(55016002)(7696005)(54896002)(6436002)(26005)(52536014)(316002)(86362001)(81156014)(7736002)(99286004)(446003)(8936002)(478600001)(2906002)(11346002)(9686003)(476003)(102836004)(81166006)(74316002)(236005)(8676002)(68736007)(606006)(186003)(53936002)(966005)(53546011)(486006)(5660300002)(6506007)(229853002)(76176011)(2501003)(790700001)(6116002)(4326008)(3846002)(66066001)(73956011)(76116006)(66946007)(66476007)(66556008)(64756008)(66446008)(25786009)(6306002)(33656002)(14444005)(561944003)(71190400001)(71200400001)(256004)(110136005)(14454004)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2563; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ShtnNqWqvPCpkGzJn4nu/pMoV2tW98gv7C0Ep5n1Mpk/yBpS09grrqABAuGFA31/4GWbfgJL9Hb/JgrtPvReTwbGmPD8EQ3XSxWAcxKC/Uzkef+aAFnq+pTIdRJZD2pgwzbfcNrV5EWxmDgRCKNWhLNkV8tBp5yO4Se/g8Brv9w3PGPeJtNvAHLBggHg8w/d1LHC5lQpjMZmmUiTVJqlIGbk2rST3zYjMZqmr/2GJOi6kclXWC329bB4K607Tb29O5PEdVS15lYwtXptaH9Apo34ca06tdsa9ncEtS4ITPG4felwzOY+g/Ny2tmAAn5DM2m8rDK1HfQGx9i2rP5pPw8K79bqcvrUo7QjNaO3Xm12rv721XnRoBop3sv2tdqBd2oV0GSUMzAh04tNMHNsjwopJyxMNqss+pj+lBbLfXw= Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2547D526E00CE7C5DDCDB3E9C91E0BN7PR11MB2547namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 90ab8776-ee73-417e-489b-08d6e37c869c X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2019 14:55:29.1493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2563 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 14:55:39 -0000 --_000_BN7PR11MB2547D526E00CE7C5DDCDB3E9C91E0BN7PR11MB2547namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, for insisting. I still have the concern that by adopting this, IETF = will continue the trend of endorsing different certificate management proto= cols and profiles (SCEP, CMPv2, CMC, EST) that mostly do the same things. S= pecifically for industrial automation we already have SCEP and EST in IE 61= 850/IEC 62351. OPC UA has its own SDP for the same purposes. Now, we want t= o add one more (CMP) in the mix for this vertical. So far I have seen one vendor that is driving this new profile. Two CAs tha= t are interested in CMP in general, but it is not clear if they are interes= ted in this exact profile. And I saw one more vendor that is interested in = CMP profiles, but I am not exactly sure if it is for this specific profile = either. Rgs, Panos From: Spasm On Behalf Of Russ Housley Sent: Monday, May 27, 2019 12:49 PM To: spasm@ietf.org Cc: Tim Hollebeek Subject: [lamps] Support for working on the lightweight CMP profile Hendrik: I see people speaking on both sides. So, I am asking a few questions to se= e if there is enough support... 1) If this work is added to the charter, will you contribute to the documen= t? 2) If this work is added to the charter, will you review to the document? 3) If this document is published as an RFC, will you implement it? Russ On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik > wrote: Hi Russ Did you have the time to look into my mail below? I would like to push this topic further forward. Hendrik Von: Brockhaus, Hendrik (CT RDA ITS SEA-DE) Gesendet: Montag, 20. Mai 2019 15:43 An: Russ Housley > Cc: Fries, Steffen (CT RDA ITS) >; spasm@ietf.org Betreff: AW: Proposed Re-Chartering Text for CMP updates and lightweight pr= ofile (RE: Follow-up on lightweight CMP profile) Hi Russ We discussed my proposal on the mailing list. I feel there is quite some su= pport. Tomas, Max and Martin supported the activity. There were some questions and= concerns from Panos, that I hopefully could clarify. What is the next step? Hendrik Von: Spasm > Im Auftr= ag von [ext] Brockhaus, Hendrik Gesendet: Mittwoch, 8. Mai 2019 11:10 An: spasm@ietf.org; Russ Housley > Cc: Jim Schaad >; Fri= es, Steffen (CT RDA ITS) > Betreff: [lamps] Proposed Re-Chartering Text for CMP updates and lightweigh= t profile (RE: Follow-up on lightweight CMP profile) Hi Russ, all, as discussed at IETF104 and on this list we would like to spend further wor= k on updating and profiling CMP focusing on industrial use cases. To get input, feedback and support from LAMPS we propose the following char= ter text. As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in indus= trial environments it needs to be enhanced to more efficiently support of i= ndustrial use cases, crypto agility and specific communication relations on= the one hand and profiled to the necessary functionality on the other hand= to ease application and to better facilitate interoperable implementation. Hendrik Von: Russ Housley > Gesendet: Mittwoch, 8. Mai 2019 02:18 An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) > Cc: spasm@ietf.org; Jim Schaad >; Fries, Steffen (CT RDA ITS) > Betreff: Re: [lamps] Follow-up on lightweight CMP profile Hendrik: The current re-charter is about two weeks away. You would need to propose = text for the charter on this list, and see if there are people that will re= view and implement. Russ On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik > wrote: Hi all Referring to the Email thread 'Seeking guidance on proceeding with question= from IETF-104 presentation on lightweight CMP profile' and to the outcome = of the WG meeting, we want to summarize the current state of the discussion= . The discussion we had with Jim motivate a split of the current draft into a= CMP Updates and a CMP Profile document. The update of CMP is needed becaus= e we identified at least two point where a change to CMP is needed: - Change the type of encryptedCert from EncryptedValue to EncryptedKey for = ECC and post-quantum algorithm support - Extend the RootCAUpdate announcement message to e request/response messag= e to enable requesting the update from the client side The remaining points from the initial email were seen as profiling topic an= d would therefore be handled in the CMP Profile document... @Russ, how do you see the status of the current re-chartering process? Woul= d you support to add both, or at least the CMP Updates, activities under th= e revised charter? - Hendrik _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm --_000_BN7PR11MB2547D526E00CE7C5DDCDB3E9C91E0BN7PR11MB2547namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Sorry, for insisting. = I still have the concern that by adopting this, IETF will continue the tren= d of endorsing different certificate management protocols and profiles (SCE= P, CMPv2, CMC, EST) that mostly do the same things. Specifically for industrial automation we already have SCEP a= nd EST in IE 61850/IEC 62351. OPC UA has its own SDP for the same purposes.= Now, we want to add one more (CMP) in the mix for this vertical.

 

So far I have seen one= vendor that is driving this new profile. Two CAs that are interested in CM= P in general, but it is not clear if they are interested in this exact prof= ile. And I saw one more vendor that is interested in CMP profiles, but I am not exactly sure if it is for this= specific profile either.

 

Rgs,

Panos

 

 

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley
Sent: Monday, May 27, 2019 12:49 PM
To: spasm@ietf.org
Cc: Tim Hollebeek <tim.hollebeek@digicert.com>
Subject: [lamps] Support for working on the lightweight CMP profile<= o:p>

 

Hendrik:

 

I see people speaking on both sides.  So, I am = asking a few questions to see if there is enough support...

 

1) If this work is added to the charter, will you co= ntribute to the document?

 

2) If this work is added to the charter, will you re= view to the document?

 

3) If this document is published as an RFC, will you= implement it?

 

Russ

 



On May 27, 2019, at 9:03 AM, Brockhaus, Hendrik <= hendrik.brockhaus@siemens.= com> wrote:

 

Hi Russ

 

Did you have the time to look into my mail below?

I would like to push this topic further forward.

 

Hendrik

 

Von:&nb= sp;Brockhaus, Hendrik (CT RDA ITS SEA-DE) 
Gesendet: Montag, = 20. Mai 2019 15:43
An: Russ Housley &= lt;hou= sley@vigilsec.com>
Cc: Fries, Steffen= (CT RDA ITS) <steffen.fries@siemens.com>; spasm@ietf.org
Betreff: AW: Propo= sed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-= up on lightweight CMP profile)

 

Hi Russ

 

We discussed my proposal on the mailing list. I feel= there is quite some support.

Tomas, Max and Martin supported the activity. There = were some questions and concerns from Panos, that I hopefully could clarify= .

 

What is the next step?

 

Hendrik

 

Von:&nb= sp;Spasm <spasm-bounces@ietf.org> Im Auftrag von [ext] Brockhaus, Hendrik
Gesendet: Mittwoch= , 8. Mai 2019 11:10
An: spasm@ietf.org;= Russ Housley <housley@vigilsec.com>
Cc: Jim Schaad <= ;iet= f@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.= fries@siemens.com>
Betreff: [lamps] P= roposed Re-Chartering Text for CMP updates and lightweight profile (RE: Fol= low-up on lightweight CMP profile)

 

Hi Russ, all,

 

as discussed at IETF104 and on this list we would li= ke to spend further work on updating and profiling CMP focusing on industri= al use cases.

To get input, feedback and support from LAMPS we pro= pose the following charter text.

 

= As certificate management gets increasingly important in industrial environ= ments, it needs to be tailored to the specific needs. CMP as existing proto= col offers a vast range of options. As it is already being applied in industrial environments it needs to be enhanced to more e= fficiently support of industrial use cases, crypto agility and specific com= munication relations on the one hand and profiled to the necessary function= ality on the other hand to ease application and to better facilitate interoperable implementation. 

 

 

Hendrik

 

Von:&nb= sp;Russ Housley <housley@vigilsec.com> 
Gesendet: Mittwoch= , 8. Mai 2019 02:18
An: Brockhaus, Hen= drik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com>= ;
Cc: spasm@ietf.org;= Jim Schaad <ietf@augustcellars.com>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com>
Betreff: Re: [lamp= s] Follow-up on lightweight CMP profile

 

Hendrik:

 

The current re-charter is about two weeks away. &nbs= p;You would need to propose text for the charter on this list, and see if t= here are people that will review and implement.

 

Russ

 

 

On May 3, 2019, at 4:52 AM, Brockhaus, Hendrik <<= a href=3D"mailto:hendrik.brockhaus@siemens.com">hendrik.brockhaus@siemens.com> wrote:

 

Hi= all

&n= bsp;

Re= ferring to the Email thread 'Seeking guidance on proceeding with question f= rom IETF-104 presentation on lightweight CMP profile' and to the outcome of= the WG meeting, we want to summarize the current state of the discussion.

Th= e discussion we had with Jim motivate a split of the current draft into a C= MP Updates and a CMP Profile document. The update of CMP is needed because = we identified at least two point where a change to CMP is needed:

- = Change the type of encryptedCert from EncryptedValue to EncryptedKey for EC= C and post-quantum algorithm support

- = Extend the RootCAUpdate announcement message to e request/response message = to enable requesting the update from the client side

Th= e remaining points from the initial email were seen as profiling topic and = would therefore be handled in the CMP Profile document...

&n= bsp;

@R= uss, how do you see the status of the current re-chartering process? Would = you support to add both, or at least the CMP Updates, activities under the = revised charter?

&n= bsp;

- = Hendrik

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

 

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

 

--_000_BN7PR11MB2547D526E00CE7C5DDCDB3E9C91E0BN7PR11MB2547namp_-- From nobody Tue May 28 13:16:19 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E0312006F; Tue, 28 May 2019 13:16:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-lamps-rfc6844bis@ietf.org, Russ Housley , lamps-chairs@ietf.org, housley@vigilsec.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155907457753.25681.2545743172638978571.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2019 13:16:17 -0700 Archived-At: Subject: [lamps] Alissa Cooper's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 20:16:18 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lamps-rfc6844bis-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please respond to the Gen-ART review. From nobody Tue May 28 13:17:38 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D601200D6; Tue, 28 May 2019 13:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=zYIsqOei; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yG251pEI 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 uWZhCsxW58rP; Tue, 28 May 2019 13:17:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A12C12006F; Tue, 28 May 2019 13:17:25 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id BB60222295; Tue, 28 May 2019 16:17:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 28 May 2019 16:17:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=p 5yKzhdiu4l0ffF/TpFk6OZ5Oc1gZC8jsZAjuKa1V1M=; b=zYIsqOeio4Z7P6Ohf VpMIi3iE64WF2DXxcE/mmBD8I5mBOEGB3iJwEOoqaQAWctcSADNoFMzYEHvcENES gTikc3H8NgM2qa2tf0J6ZeKcWBzCNVkJVXF1SUqU4gsxod5itmirpYCRQdTFrTMf uZCGrtW+Av9DKc/rmxLOmg2qqqOb9WZhXvTox4x14D+fNrcib1j1IYPyq3mJU9NW HSlshOErWt3VsoR5ngkkDPIVZA7qlpqdMSaPz7xEKRhJ2b/syqXQebgtsMnRCjVi R8duBE7DngvPNtriTu9Q+vpHi/KuzlC9HQXHf7zYEDYCisuxgAih0qgsxorntb/0 xGqqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=p5yKzhdiu4l0ffF/TpFk6OZ5Oc1gZC8jsZAjuKa1V 1M=; b=yG251pEIoaJHjzScy4jymUvXJ8tEDn0p91SJB+8xbreqrjb4dsU2SH7Ie aq1TGsjVN0DERaRVKi1k4WBdNsyKGE62GDbKpeL3u+L0X5gR+3DGXN96KHpH4Jfv FtSkhCenpg8epCk0zgGK11AyW2jytVEfdoMAJmUeSoDTJ940dAcIUS47CiUIALtF T2Pa9Gxp6cItkPcYIEGxilD9/BPXAoa//hLtYiATmWXxPXonxWe+nCbn8JGSwCoh I0SY24TD1TUhUs63hNeiQzp7vzbSgUbQfo7CwFHJm957wdOxH0iHfFlDw5ak1rgO 8br2YiO18YnKX9uB0q5fLL5qckRYw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddvhedgudegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhi shhsrgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomh grihhnpehivghtfhdrohhrghdpvgigrghmphhlvgdrtghomhenucfkphepudejfedrfeek rdduudejrdejfeenucfrrghrrghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhoph gvrhifrdhinhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id C229B80069; Tue, 28 May 2019 16:17:23 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155792831007.17593.15497489606283752991@ietfa.amsl.com> Date: Tue, 28 May 2019 16:17:31 -0400 Cc: gen-art@ietf.org, spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc6844bis.all@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155792831007.17593.15497489606283752991@ietfa.amsl.com> To: Peter Yee X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Gen-art] Genart last call review of draft-ietf-lamps-rfc6844bis-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 20:17:31 -0000 Thanks Peter. I entered a No Objection ballot pointing to your review. Alissa > On May 15, 2019, at 9:51 AM, Peter Yee via Datatracker = wrote: >=20 > Reviewer: Peter Yee > Review result: Ready with Issues >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-rfc6844bis-06 > Reviewer: Peter Yee > Review Date: 2019-05-15 > IETF LC End Date: 2019-05-08 > IESG Telechat date: Not scheduled for a telechat >=20 > Summary: Ready with Issues. This draft is an update to RFC 6844 = dealing with > the CAA RR used to notify CAs as to which CA(s) are allowed to issue > certificates for a particular domain. The issues and nits I note are = rather > minor. Apologies for the lateness of this review. >=20 > Major issues: >=20 > Minor issues: >=20 > Page 10, 2nd paragraph: the appearance of "sub.wild.example.com" = presupposes > that there was no other RRset that matched sub.wild.example.com (or a = "deeper" > domain name) already. That assumption should be noted in this = paragraph. >=20 > Page 13, section 5.6: a little context should be given here. This = abuse is > only plausible if the domain owner is being given the RRset data by = the CA > rather than generating that data itself. >=20 > Nits/editorial comments: >=20 > Page 5, 1st partial paragraph: change "with" to "within". >=20 > Page 5, 1st full paragraph: regarding the reference to Section 4, = shouldn't > this actually be Section 3? >=20 > Page 8, definition of "Value", 2nd sentence: delete redundant "the". >=20 > Page 15, 1st partial paragraph, 1st partial sentence: change "use" to = "used". >=20 > Page 15, section 7, 2nd paragraph: is there a reference available for = the term > "WebPKI"? >=20 > Page 15, section 7, 3rd paragraph, 1st sentence: insert "the" before = "issue". >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue May 28 15:37:11 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF93C120047 for ; Tue, 28 May 2019 15:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMsH8pUbP1vX for ; Tue, 28 May 2019 15:37:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D74E0120018 for ; Tue, 28 May 2019 15:37:07 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 3895838270 for ; Tue, 28 May 2019 18:36:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 55CE6D78; Tue, 28 May 2019 18:37:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 53349A8A for ; Tue, 28 May 2019 18:37:04 -0400 (EDT) From: Michael Richardson To: "spasm\@ietf.org" In-Reply-To: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 22:37:10 -0000 --=-=-= Content-Type: text/plain Panos Kampanakis (pkampana) wrote: > Sorry, for insisting. I still have the concern that by adopting this, IETF > will continue the trend of endorsing different certificate management > protocols and profiles (SCEP, CMPv2, CMC, EST) that mostly do the same > things. Specifically for industrial automation we already have SCEP and EST > in IE 61850/IEC 62351. OPC UA has its own SDP for the same purposes. Now, we > want to add one more (CMP) in the mix for this vertical. I agree with Panos. I don't really know why we need CMP, let alone a lightweight CMP. Plus we have a bunch of proprietary RESTful interfaces to CAs. I have less of an objection to the IETF doing something, but I won't be reading/editing or implementing. If anything, I'd like to remove features from the protocols we have to simplify them and focus them better. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlztuBAACgkQgItw+93Q 3WUD8wgAgU10244x7EqP0XHxi+4LhmjbhtloWg/wplK612NXCQO5axgLrHKYp1/z ZWF+BPitey02F+6JF2IkT6D7NfFDJrO3/i1gkOEaPYEQRnUgAbYgBDiBnw0Wtx2o rQSOwnREmRTigF+vYS9Re8oBi0a7X3NjhCLhAZz3UwHwXhZEVjbX3UEBdwdxtrn9 KB+T8X/59gAjj4jt+jZYcq30YMHHaRtedVi3/W4LI1ues6wSOllpFMbcXNRW2jRM k1Lyor3ZZiYSZeLFL2pWKYxEuAmxZLC/skoWR6cXa90oHUjd/cao6Qavl8HFprlz zcVwVwxL4VPiVasIGHHRIh2F66edug== =AjF4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue May 28 18:27:41 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8780D1200A4; Tue, 28 May 2019 18:27:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <155909325854.25685.7606945479341276185.idtracker@ietfa.amsl.com> Date: Tue, 28 May 2019 18:27:38 -0700 Archived-At: Subject: [lamps] Alissa Cooper's No Objection on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 01:27:39 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-lamps-hash-of-root-key-cert-extn-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The CTIA acknowledgement seems unusual since it doesn't acknowledge any actual contribution to the document. From nobody Tue May 28 18:28:31 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF0E1200F1; Tue, 28 May 2019 18:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=GEKaYcuB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lK8fMPOJ 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 X-ys5-_J2mP3; Tue, 28 May 2019 18:28:27 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77CB1200A4; Tue, 28 May 2019 18:28:24 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DC07221B8C; Tue, 28 May 2019 21:28:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 28 May 2019 21:28:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=W 0M28V+W6drNXhgeKlTJO/BdcrjnQEedIyO4A6iJLyU=; b=GEKaYcuBZlSpnLgNj wLQOALymdG79dbewN/NBw/KO6O4OcdY8OJJfN7Z0csakw+oQrUVCCBcLnn28SBBk BtkkEEgr/j+/xXpOPrO4cv/K127j0eyOMsWfjUgh+cEPe9zhXaBvw151Q/2P2Sb+ KISobBl4wHLNByj3YfxS4WuN8FC4Md74vB4xaQZ72gu2fmV871+OJXRjHxsC84nT dhfBDYJDFdkhlWaIEk966mxkiwYoec5hftx4S43AdvJ2uH/8e2ew+eD7qPkatzxu e6ghJwwO5nN90qIZPk+GNr7JSWfVINr2CpjFRy3l8dm/cdF4ONu/7JZrOYZgbEza CgdJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=W0M28V+W6drNXhgeKlTJO/BdcrjnQEedIyO4A6iJL yU=; b=lK8fMPOJsjmzr6E2n+T7Iynf+8wfHLtSDPpQcRgl37uLbhCsUjkP0Gz5A /moO/nekhk2T5M8m1/12/hk74402FxOPSgrOCiicutL5vrkp+ZViSoQ0Xcf1Jr5f 8QM7InMJZUNb3qzsWnx7dven26lbUO6oOlGpjYsnbIhhpILqfdZTQUrAlG2ye2tj QYc7W09RxKLzsI3PDrcncrULYruUr/33CcRfLEgfGHilv+/Yfh+dvkq/IA+shsHz y2GhDAdzHB5zhkfKmYP1vN5Y81FZ8CV0R+j7KrtlOyCSkYwxlSTn8ECBV7BmbJrw PS7Lnrav9zreqcvTYZCReDAkmTAVQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddruddviedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrjeefnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd X-ME-Proxy: Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.73]) by mail.messagingengine.com (Postfix) with ESMTPA id BAD4F8005C; Tue, 28 May 2019 21:28:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alissa Cooper In-Reply-To: <155848724103.2726.16872458550460720675@ietfa.amsl.com> Date: Tue, 28 May 2019 21:28:30 -0400 Cc: IETF Gen-ART , spasm@ietf.org, draft-ietf-lamps-hash-of-root-key-cert-extn.all@ietf.org, ietf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <48C87E92-B18C-405B-9E01-64F6DF5266FA@cooperw.in> References: <155848724103.2726.16872458550460720675@ietfa.amsl.com> To: Joel Halpern X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [lamps] [Gen-art] Genart telechat review of draft-ietf-lamps-hash-of-root-key-cert-extn-05 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 01:28:30 -0000 Thanks Joel. I entered a No Objection ballot. Alissa > On May 21, 2019, at 9:07 PM, Joel Halpern via Datatracker = wrote: >=20 > Reviewer: Joel Halpern > Review result: Ready >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. >=20 > For more information, please see the FAQ at >=20 > . >=20 > Document: draft-ietf-lamps-hash-of-root-key-cert-extn-05 > Reviewer: Joel Halpern > Review Date: 2019-05-21 > IETF LC End Date: None > IESG Telechat date: 2019-05-30 >=20 > Summary: This Internet Draft is ready for publication as an = Informational RFC >=20 > Major issues: N/A >=20 > Minor issues: N/A >=20 > Nits/editorial comments: N/A >=20 >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Tue May 28 23:14:26 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB812008B for ; Tue, 28 May 2019 23:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VM_KsFbUvg_J for ; Tue, 28 May 2019 23:14:22 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 38212120045 for ; Tue, 28 May 2019 23:14:22 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x4T6EJ0o021068 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 May 2019 08:14:19 +0200 Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net [139.22.70.141]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x4T6EIJi024404 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 May 2019 08:14:19 +0200 Received: from DENBGAT9EREMSX.ww902.siemens.net (139.22.70.81) by DEFTHW99ERNMSX.ww902.siemens.net (139.22.70.141) with Microsoft SMTP Server (TLS) id 14.3.435.0; Wed, 29 May 2019 08:14:18 +0200 Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([169.254.12.220]) by DENBGAT9EREMSX.ww902.siemens.net ([139.22.70.81]) with mapi id 14.03.0435.000; Wed, 29 May 2019 08:14:17 +0200 From: "Fries, Steffen" To: Michael Richardson , "spasm@ietf.org" Thread-Topic: [lamps] Support for working on the lightweight CMP profile Thread-Index: AQHVFaXqgLz2N8gj8ki0bie+pF7r+aaBnxcg Date: Wed, 29 May 2019 06:14:17 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> In-Reply-To: <17374.1559083024@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 06:14:24 -0000 Michael Richardson wrote: > Panos Kampanakis (pkampana) wrote: > > Sorry, for insisting. I still have the concern that by adopting thi= s, IETF > > will continue the trend of endorsing different certificate manageme= nt > > protocols and profiles (SCEP, CMPv2, CMC, EST) that mostly do the s= ame > > things. Specifically for industrial automation we already have SCEP= and EST > > in IE 61850/IEC 62351. OPC UA has its own SDP for the same purposes= . Now, we > > want to add one more (CMP) in the mix for this vertical. >=20 > I agree with Panos. > I don't really know why we need CMP, let alone a lightweight CMP. > Plus we have a bunch of proprietary RESTful interfaces to CAs. >=20 > I have less of an objection to the IETF doing something, but I won't be r= eading/editing or implementing. >=20 > If anything, I'd like to remove features from the protocols we have to si= mplify them and focus them better. That exactly is the intention of lightweight CMP. It intends to strip down = functionality from an IETF defined protocol to have less requirements for i= nteroperability for implementing devices. This lightweight approach should = make it easier for others to adopt the already standardized functionality i= nstead of defining proprietary approaches with a similar functionality.=20 Best regards Steffen From nobody Wed May 29 03:43:47 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181C712009E for ; Wed, 29 May 2019 03:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=J1+D5XXJ; dkim=pass (1024-bit key) header.d=primekey.com header.b=J1+D5XXJ 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 EdxZ-VoT1m3q for ; Wed, 29 May 2019 03:43:41 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60239120019 for ; Wed, 29 May 2019 03:43:41 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id ADA006AA008D for ; Wed, 29 May 2019 12:43:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1559126614; bh=Rf2FOl1iyFgMWwKrAuxgviL/HJYE6i3HiTUo/XI5phs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=J1+D5XXJHfHVLxpYurkHa+SY4diZ//VBCmW2mPxBnN+hG/gWNIYe/LywcpZ7XM1BY fy9E39yBgyZCpYNGhuFOXKPmVZr9LRS0BzgelB62VBCyEyp2CMCy3YaT//78p6YgtN aqvQ0Xbcl0kVrHeH6D0DLOqGaV1pWCGbSYXL0tCk= Received: from [192.168.3.184] (gatekeeper.primekey.se [84.55.121.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 8F20E6AA006D for ; Wed, 29 May 2019 12:43:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1559126614; bh=Rf2FOl1iyFgMWwKrAuxgviL/HJYE6i3HiTUo/XI5phs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=J1+D5XXJHfHVLxpYurkHa+SY4diZ//VBCmW2mPxBnN+hG/gWNIYe/LywcpZ7XM1BY fy9E39yBgyZCpYNGhuFOXKPmVZr9LRS0BzgelB62VBCyEyp2CMCy3YaT//78p6YgtN aqvQ0Xbcl0kVrHeH6D0DLOqGaV1pWCGbSYXL0tCk= To: spasm@ietf.org References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Wed, 29 May 2019 12:43:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 10:43:45 -0000 Hi, I want to give my reasons for having a CMP profile. From the viewpoint of a product implementor implementing open standards for PKI. Sorry for the lengthy post, but I have several arguments :-) Please don't mention SCEP in this context. SCEP is not an RFC and does not fulfill even basic needs of today (EC). SCEP is quickly going away and it's best to leave it alone to die. CMC I would agree does some of the same functionality, but it's also dying. Leave it to rest. We have today two (good) alternatives for standard PKI protocols, CMP and EST. As a product supplier we see extensive use of both CMP and EST in the industry and the more interoperable these usages are the better. EST and CMP have fundamentally different security aspects, making them suitable for different use cases. It's not one of the other, both are needed due to the different ways of working: - EST uses the communication layer (TLS) for security, it is simple and easy, but depends on TLS (for good and for bad, mostly for good where this approach is suitable) - CMP uses message security and is independent of the communication layer, the messages are self-sufficient (for good and for bad, mostly for good where this approach is suitable) EST and CMP are not competing standard, but very much complementary and as product implementor we like them both. Unfortunately CMP (RFC4210) is more of a framework and solutions are not interoperable because they use fields in different ways. Profiling is needed. The best profiling of CMP that I have seen so far is 3GPP 33.310 in telecom, enabling vendors and telcos to use devices from multiple manufactures in an interoperable way, using standard products without custom development. https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2293 There is profiling going on for EST, see EST over Secure CoAP for example. https://tools.ietf.org/html/draft-ietf-ace-coap-est-11 So it is not unheard of that IETF creates profiles to support different use cases. Considering the security aspects of CMP, and that it is used extensively within the industry today, making a profile is highly valuable to counter interoperability issues arising from the framework approach of RFC4210. I am glad to see that IEC 62351 is using standard protocols and has not invented it's own. What would be interesting is to compare the proposed profile agains what 62351 suggest. At least on the wikipedia page: https://en.wikipedia.org/wiki/IEC_62351 It claims "Certificate enrollment by means of SCEP / CMP / EST", hence usage of CMP already. How does IEC 62351 profile CMP? IEC 62351 is a for purchase standard, and those rarely get high traction except for their limited scope/vertical. In contrast, IETF documents get traction across the board of protocol users. This is one reason why I see the suggested profile having the potential to lift CMP up to a more interoperable level, not only for the IIoT vertical, but actually re-used for other verticals as well. IMHO, it should be profiled in openness in IETF, not in closedness in IEC. It's not a question if the profile (yes stripping down CMP) will exist or not, just a question of where it is housed. My opinion is that IETF is the best place. I like IETF standards, and they are highly referenced and spread, making the world just a little bit more interoperable. Regards, Tomas On 2019-05-29 08:14, Fries, Steffen wrote: > Michael Richardson wrote: >> Panos Kampanakis (pkampana) wrote: >> > Sorry, for insisting. I still have the concern that by adopting this, IETF >> > will continue the trend of endorsing different certificate management >> > protocols and profiles (SCEP, CMPv2, CMC, EST) that mostly do the same >> > things. Specifically for industrial automation we already have SCEP and EST >> > in IE 61850/IEC 62351. OPC UA has its own SDP for the same purposes. Now, we >> > want to add one more (CMP) in the mix for this vertical. >> >> I agree with Panos. >> I don't really know why we need CMP, let alone a lightweight CMP. >> Plus we have a bunch of proprietary RESTful interfaces to CAs. >> >> I have less of an objection to the IETF doing something, but I won't be reading/editing or implementing. >> >> If anything, I'd like to remove features from the protocols we have to simplify them and focus them better. > That exactly is the intention of lightweight CMP. It intends to strip down functionality from an IETF defined protocol to have less requirements for interoperability for implementing devices. This lightweight approach should make it easier for others to adopt the already standardized functionality instead of defining proprietary approaches with a similar functionality. > > Best regards > Steffen > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm > From nobody Wed May 29 05:00:42 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229A4120116 for ; Wed, 29 May 2019 05:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epiM8HGoHjHF for ; Wed, 29 May 2019 05:00:38 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20118.outbound.protection.outlook.com [40.107.2.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3857D1200C1 for ; Wed, 29 May 2019 05:00:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ey6AtBABpXYLgaqoJpwcJ9B3kekS68lnWrlgUupUG1s=; b=fu7wvP6fo/CtZDNtXHvvEjLSwfYAGwFz83Rcc0kmpWTb91EWh3xjiXUvetnat3KRFPf0QsKD5xEx5MZgSYUk4TsgH+x19TumtWpLVQe39UI9h7ffggKrmBf2HGwEijGKNhND2l++e/cRezxS5Ujtt6oYm79znHA09LFdF3XrUgo= Received: from HE1PR0701MB2444.eurprd07.prod.outlook.com (10.168.130.8) by HE1PR0701MB2747.eurprd07.prod.outlook.com (10.168.188.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.13; Wed, 29 May 2019 12:00:33 +0000 Received: from HE1PR0701MB2444.eurprd07.prod.outlook.com ([fe80::4457:ee7d:f295:6ceb]) by HE1PR0701MB2444.eurprd07.prod.outlook.com ([fe80::4457:ee7d:f295:6ceb%9]) with mapi id 15.20.1943.015; Wed, 29 May 2019 12:00:33 +0000 From: "Peylo, Martin (Nokia - FI/Espoo)" To: Michael Richardson , "spasm@ietf.org" Thread-Topic: [lamps] Support for working on the lightweight CMP profile Thread-Index: AQHVFKwNiB+RnXVsz0qy43JaaEsToaaAoW+AgACA9wCAANis4A== Date: Wed, 29 May 2019 12:00:33 +0000 Message-ID: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> In-Reply-To: <17374.1559083024@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=martin.peylo@nokia.com; x-originating-ip: [131.228.2.0] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3044f27b-0b7d-4cea-ba93-08d6e42d4122 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:HE1PR0701MB2747; x-ms-traffictypediagnostic: HE1PR0701MB2747: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2399; x-forefront-prvs: 0052308DC6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39850400004)(376002)(366004)(136003)(13464003)(189003)(199004)(76116006)(186003)(26005)(55016002)(81166006)(8936002)(11346002)(476003)(6436002)(110136005)(14454004)(478600001)(229853002)(446003)(9686003)(8676002)(486006)(66946007)(66556008)(53546011)(6506007)(66476007)(316002)(66446008)(64756008)(73956011)(81156014)(7736002)(76176011)(7696005)(6246003)(3846002)(6116002)(68736007)(66066001)(305945005)(53936002)(25786009)(5660300002)(52536014)(102836004)(71190400001)(256004)(2906002)(2501003)(74316002)(86362001)(71200400001)(33656002)(99286004)(7756004); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB2747; H:HE1PR0701MB2444.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4hv476/nruz8EqrXGOHkBEO4h/U+CqBvRf25GUbKMo13ptUTNog52ZdJ6lXSwsv54uSiYgqN4n31lDlitbBLgPvdHUmUbT6kNzXVMJSW/Vw4I6JWKSIZtDplEhJ/xeaeFr1J7WNUST83uRGVtxVPQQ43U/tqbJqpmOGnxxwOmtVMVUT5rmuV5OR79tG4GRBrYWk5d90jOq78mMZDCv251D45g1EutZoWdsx6x2IpScviv1sPIyKIPE9tJdr3OqHrLnuy0dvY7MrprNM9Jc/JK4oRjNVBXUiEp9HY1SqB7vOlI5J6yfWwVZlOdHo940vA3U/gaGnShxFwFLc2DZMJXqkXGrNJE+DckK/TST8abjZFb6nS7dxcpu6JAi+T8jeV1uwARtlmTcdJNrwt8swhhx7oqyc1PSn+DoyS41vkSpI= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3044f27b-0b7d-4cea-ba93-08d6e42d4122 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 12:00:33.4978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: martin.peylo@nokia.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2747 Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 12:00:40 -0000 Hi Michael, > I don't really know why we need CMP, let alone a lightweight CMP. Obviously, I also cannot say why you would need CMP, but e.g. the telco ind= ustry understands it, and therefore we are using it actively. I also know t= hat the FOSS CMP implementation is utilized actively by more silent users i= ncluding the banking, IT, academia fields.=20 To ease standard conforming, interoperable implementation for various use c= ases where EST and SCEP are totally useless (e.g. RA-CA interface), it'd be= great to have some standards-track clarifications (=3D profiling). Profili= ng CMP would be more or less this "remove features" you're asking for, as t= he richness of options in CMP wasn't necessarily beneficial for out-of-the-= box interoperability in the past. One should note that the subject of this email seems to be somewhat mislead= ing as it is overly limiting the scope. I expect that besides clarification= s for e.g. RA-CA communications, the upcoming work will also include a refr= esh of mandatory algorithms (bye bye SHA-1). While both of those will certa= inly be beneficial also for the lightweight CMP on the interface to EEs, it= will also have positive influence beyond the "lightweight CMP" scope. > Plus we have a bunch of proprietary RESTful interfaces to CAs. As they are proprietary, they seem to be somewhat out of IETF scope and int= eroperability might not have been your focus when you were creating those? Cheers, Martin -----Original Message----- From: Spasm On Behalf Of Michael Richardson Sent: Wednesday, May 29, 2019 1:37 AM To: spasm@ietf.org Subject: Re: [lamps] Support for working on the lightweight CMP profile Panos Kampanakis (pkampana) wrote: > Sorry, for insisting. I still have the concern that by adopting this,= IETF > will continue the trend of endorsing different certificate management > protocols and profiles (SCEP, CMPv2, CMC, EST) that mostly do the sam= e > things. Specifically for industrial automation we already have SCEP a= nd EST > in IE 61850/IEC 62351. OPC UA has its own SDP for the same purposes. = Now, we > want to add one more (CMP) in the mix for this vertical. I agree with Panos. I don't really know why we need CMP, let alone a lightweight CMP. Plus we have a bunch of proprietary RESTful interfaces to CAs. I have less of an objection to the IETF doing something, but I won't be rea= ding/editing or implementing. If anything, I'd like to remove features from the protocols we have to simp= lify them and focus them better. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Wed May 29 08:25:42 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53912015F for ; Wed, 29 May 2019 08:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEVpXNQQSR7X for ; Wed, 29 May 2019 08:25:39 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46A512015E for ; Wed, 29 May 2019 08:25:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BB869300AEA for ; Wed, 29 May 2019 11:06:21 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id id0f04hEFi-5 for ; Wed, 29 May 2019 11:06:20 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 3EE593005C6; Wed, 29 May 2019 11:06:20 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <155909325854.25685.7606945479341276185.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2019 11:25:37 -0400 Cc: IESG , SPASM , Tim Hollebeek Content-Transfer-Encoding: quoted-printable Message-Id: References: <155909325854.25685.7606945479341276185.idtracker@ietfa.amsl.com> To: Alissa Cooper X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Alissa Cooper's No Objection on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 15:25:41 -0000 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > The CTIA acknowledgement seems unusual since it doesn't acknowledge = any actual > contribution to the document. Alissa: The OIDs that are used come from the CTIA arc. Perhaps this would be = better: CTIA - The Wireless Association - is developing a public key infrastructure that will make use of the certificate extension described in this document, and the object identifiers used in the ASN.1 module were assigned by CTIA. Russ From nobody Wed May 29 11:18:49 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED48A120158 for ; Wed, 29 May 2019 11:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com header.b=CkRgz2Zw; dkim=pass (1024-bit key) header.d=digicert.com header.b=DtvHFBjU 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 rGsEcp-cBMzx for ; Wed, 29 May 2019 11:18:42 -0700 (PDT) Received: from us-smtp-delivery-173.mimecast.com (us-smtp-delivery-173.mimecast.com [216.205.24.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C79D12004F for ; Wed, 29 May 2019 11:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=mimecast20190124; t=1559153921; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:openpgp:autocrypt; bh=LxujELyLZ0KUxUGEv2iEwGBmTqjy/7rwdNX/u/vOwDE=; b=CkRgz2Zw+1+XRhvl5AQsB4FViY1c0SRmwl65K5uE2jUeUktV/j2dAeaSf/HiFKg6ss82RI TBgD4EOQRbTgaUID/cNVxDx5bA9ecz556Q18bWo4LqYOM28FkY+WueD3AX25uS0hcPExz7 wWYoQ0PiD78Z7ClOeKznjaRYJMVAqJA= Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-co1nam05lp2059.outbound.protection.outlook.com [104.47.48.59]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-173-b_sfHckyOie_2BHLRa2s-Q-1; Wed, 29 May 2019 14:18:38 -0400 X-MC-Unique: b_sfHckyOie_2BHLRa2s-Q-1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LxujELyLZ0KUxUGEv2iEwGBmTqjy/7rwdNX/u/vOwDE=; b=DtvHFBjU0DDOYzZkqMuEqfR5+jJKJjp5jemJmgjhulNMPhpQWumbHMx3Zwp0Ek7mqQqUdED9ePtjb/B4LKiuC5SEW4t48F9PWXAdI/UTwIyZ3lbGCTiJBmvJuYOhNX/t7GBhvjQezJqZ21daW5a320zp1o/DdamxDz9/x6DnAH8= Received: from MWHPR14MB1533.namprd14.prod.outlook.com (10.173.233.145) by MWHPR14MB1216.namprd14.prod.outlook.com (10.173.101.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1922.20; Wed, 29 May 2019 18:18:36 +0000 Received: from MWHPR14MB1533.namprd14.prod.outlook.com ([fe80::b9aa:dc2e:2670:8d4f]) by MWHPR14MB1533.namprd14.prod.outlook.com ([fe80::b9aa:dc2e:2670:8d4f%7]) with mapi id 15.20.1922.021; Wed, 29 May 2019 18:18:36 +0000 From: Tim Hollebeek To: "Hammell, Jonathan F" , "'spasm@ietf.org'" Thread-Topic: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk Thread-Index: AdUUjUhsTWU98srlTk2AlTzaw5oH1ABvY4hQ Date: Wed, 29 May 2019 18:18:36 +0000 Message-ID: References: <20190527133129.7B27312001A@ietfa.amsl.com> In-Reply-To: <20190527133129.7B27312001A@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tim.hollebeek@digicert.com; x-originating-ip: [98.111.253.32] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d57944dc-8a9a-43a6-0c88-08d6e4621112 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:MWHPR14MB1216; x-ms-traffictypediagnostic: MWHPR14MB1216: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1923; x-forefront-prvs: 0052308DC6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(136003)(346002)(39860400002)(189003)(199004)(13464003)(110136005)(33656002)(966005)(14454004)(478600001)(305945005)(6506007)(53546011)(55016002)(9686003)(76176011)(6306002)(102836004)(66946007)(66616009)(76116006)(66446008)(64756008)(66556008)(66476007)(73956011)(7736002)(99286004)(7696005)(71190400001)(71200400001)(5660300002)(6436002)(66066001)(2906002)(68736007)(5024004)(14444005)(256004)(316002)(6116002)(3846002)(486006)(81156014)(476003)(86362001)(53936002)(186003)(11346002)(81166006)(229853002)(8676002)(26005)(25786009)(446003)(8936002)(44832011)(99936001)(6246003)(74316002)(52536014)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1216; H:MWHPR14MB1533.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TRe1LOZxAseXDHJA74tK2Lv7FgCP1IKnonkL3Sfmx3A1eFSKH/YrJl/Xide3swdFoOCQBn8sLcuiXDb5hwCQJHbeU5C+nlEtSn2+9OF6eI+5lJTm84ammQ4FrPZZ5Pgf2mfNL52uxuFZsZG2XIpK8NfHZB2gzhgEVzY9advfkXE5ISE2JE+coWPnnVx7KNa24pa12pIz3oT/vh1uH+kwvSqO0CES4ZC8FMas7h+TgzYytc/Gfo8Aoqzjtddz9oMuGg1C7Er3NiEJbhYZ8LfPbBO3mxyCFeD9xg8uoR5fiOFSCT/iXgH5ph7OykYk0Ae9aqHESFY4fCEshQcuIPxcvdmbCZ/8i0J+ykgQpT/SL932RU/Gjbr8j1an3jeNEV6vRPPvR0F8+jS9GnkS4Brz+K3PWSzntfg20qstOm0yaeU= Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0327_01D51629.57243AC0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: d57944dc-8a9a-43a6-0c88-08d6e4621112 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 May 2019 18:18:36.2966 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tim.hollebeek@digicert.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1216 Archived-At: Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 18:18:47 -0000 ------=_NextPart_000_0327_01D51629.57243AC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thanks for doing this, this is really interesting and useful. -Tim > -----Original Message----- > From: Spasm On Behalf Of Hammell, Jonathan F > Sent: Monday, May 27, 2019 9:31 AM > To: 'spasm@ietf.org' > Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk > > Classification: UNCLASSIFIED > > Sorry for the late comment. My colleagues and I did review the draft and we > have no suggestions for text changes. We also produced a ProVerif model > (attached) in an attempt to verify some of the cryptographic properties. > Details are below. Let me know if you have any questions or issues. > > # Assumptions/limitations > The model is limited to the Key Agreement algorithm and is bounded with two > hardwired originators and hardwired recipients. > > We assume the DH key exchange is broken using a quantum computer such > that the recipient private keys are known at the outset. We have modeled this > by revealing the recipient's DH private key on the channel. > > All recipients have DH certificates signed by a trusted CA. These are shared > with all at beginning of the protocol. > > In an effort to model configuration choices of key encryption and kdf > algorithms, we included settings for using strong or weak algorithms (in the > quantum perspective). The model allows the attacker to modify the settings to > both the originator and the receivers' algorithm configuration to use quantum- > vulnerable algorithms. > > # Security queries > Our interpretation of the draft is that it is attempting to solve the problem of > maintaining the confidentiality of an encrypted cek from an opponent with the > ability to break the DH public keys with a quantum computer. Therefore our > model is limited to proving confidentiality of the cek in the face of such an > attacker. > > The model contains two types of queries: > > 1. Sanity - Whenever a sender s sends an encrypted version of cek to an > intended recipient r then recipient r receives the same cek from sender s . > > 2. Confidentiality- An attacker cannot learn the cek during a protocol run > unless the sender uses weak crypto (in the quantum perspective). > > # Running the model > proverif -graph . Using_PSK_in_CMS_Keyagree.pv > > ProVerif spits out a lot of info, but the important statements about the queries > are prefixed by the string "RESULT". > > > > --- > Re: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk Russ Housley > Fri, 10 May 2019 15:00 > UTChttps://mailarchive.ietf.org/arch/browse/spasm/?q=mix-with-psk > The only comment that I received is to add at the top of the > ASN.1 module and at the bottom of the ASN.1 module. I will do > that now. > > Russ > > > > On May 10, 2019, at 10:52 AM, Tim Hollebeek > > > > It appears no one has any further comments on this document, and it is > ready to proceed. > > > > -Tim > > > > From: Spasm > > On Behalf Of Tim Hollebeek > > Sent: Friday, April 19, 2019 10:45 AM > > To: SPASM > > > Subject: [lamps] WG Last Call for draft-ietf-lamps-cms-mix-with-psk > > > > This is the LAMPS WG Last Call for "Using Pre-Shared Key (PSK) in the > Cryptographic Message Syntax (CMS)" . > Please review the document and send your comments to the list by 6 May > 2019. > > > > The datatracker page for the document is > > https://datatracker.ietf.org/doc/draft-ietf-lamps-cms-mix-with-psk/ > > > E > > > > Thanks, > > > > Tim > ------=_NextPart_000_0327_01D51629.57243AC0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTkwNTI5MTgxODA4WjAvBgkqhkiG9w0BCQQxIgQg14PchXYsOGZjfvVtnps2BEr/8/lT Q+9gD+GDcE1LG8QwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAMlYdIRmVziuoigR5dv3zf2RW8EZ46H15RQOz24Ajq9tKLpieaRPXYA8nbWGIf8rkdlbsbZA AsK3NwJZWgk+wC7oDZvcfz8vLzGmEgC93Rqm9zVab4BAXiR+b30clPpst4JULj9l3kvNwJk/1YOP 5qMs5m1IB1WlBt53nrSGOdZxiT0yiB3tSe7deVdogWIDZJAY3SL9ihROII2VRtxCPov9S76LubkW kKawMUqLrqfjNBj4sEHqyJufsj1e8cRSQGeZXXO3fCCKcVcy0u+pBoxkAx0L2vRBUKN1U7Z1/MWw pHwZLG5HbgYBM60uCKu22BOxGfFy8sDMk2PYAgRTUS0AAAAAAAA= ------=_NextPart_000_0327_01D51629.57243AC0-- From nobody Wed May 29 15:44:06 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F62120148; Wed, 29 May 2019 15:44:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-lamps-hash-of-root-key-cert-extn@ietf.org, Tim Hollebeek , lamps-chairs@ietf.org, tim.hollebeek@digicert.com, spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> Date: Wed, 29 May 2019 15:44:06 -0700 Archived-At: Subject: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 22:44:06 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-lamps-hash-of-root-key-cert-extn-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-lamps-hash-of-root-key-cert-extn/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- After further reflection, I think we need to resurrect the discussion sparked by DKG's last-call review. Specifically, in Section 5 when we consider the case that there is not a directory service/repository available, we give guidance to "the recipient" and "recipients". But in at least some cases, there are two tiers of recipients/relying parties, that have different properties, as in the web PKI situation. Specifically, web server operators rely on root CAs to certify the certificates that they present to TLS clients. But we also consider the TLS clients themselves, which may not have a direct path to receiving the updated root CA self-signed certificate, and because of the different ways these different types of recipient rely on root CA information, the order in which they update can cause breakage. We do not necessarily need to present a clear solution that will always avoid this breakage, but I do think we need to at least discuss the possibility of such scenarios. To consider a concrete case, consider a system with a TLS client ("A"), a TLS server ("B"), and the root CA ("C"). C issues (potentially via intermediates) an end-entity certificate for B, and we consider a case where A initiates TLS connections to B. Initially, C has the root CA/key at C1, and is initiating a transition to C2; before the transition both A and B have C1 in their trusted store. When A receives C2, it can perform the requisite validation and add C2 to its trust store for use potentially validating incoming certificate chains. When B receives C2, it can similarly perform the requisite validation and add C2 to its trust store, but B's trust store is used for validating *outgoing* certificate chains, not (just) incoming ones. If B were to keep C2 in its trust store and construct an outgoing certificate chain based on C2 (and omitting oldWithNew and newWithOld), before A has received C2, then the TLS handshake fails! If A had access to C2, or to oldWithnew/NewWithOld, then it would still be able to validate B's certificate chain, but this document (and RFC 4210) do not give guidance that B should transmit newWithOld to A, leaving open this scenario for breakage. My current inclination is to add some text to this document acknowleding the potential for a chain of relying parties, and recommending that the "intermediate parties" in the scenario make newWithOld/oldWithNew available until the notAfter time from oldWithNew, but I am of course open to further discussion/suggestions. Separately, I just want to quickly check that the id-ce-hashOfRootKey OID has been properly allocated and recorded, as I couldn't find evidence to indicate that in a quick search. I assume this is the origin of the CTIA acknowledgment that Alissa mentions, but there's not quite enough there to connect the dots. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.1 Please use the boilerplate from RFC 8174 (yes, I read the shepherd writeup). Section 1.2 side note: this claim about "always encoded with DER" seems a bit optimistic unless scoped down to a specific context. Section 5 After issuing the oldWithNew and newWithOld certificates, the Root CA MUST stop using the old private key to sign certificates. Isn't this only relevant for newWithOld? We don't need to use the old private key to sign certificates to make a certification of the old key signed by the new key. Changing names from one generation to another can lead to confusion when reviewing the history of a trust anchor store. To assist with such review, a recipient MAY create an audit entry to capture the old and replacement self-signed certificates. It seems like there may be non-name changes that might also cause confusion (or worse); do we want to mention this possibility and/or the recipient's duty to check for unexpected changes? Section 6 I think some explicit guidance is needed about there being a critical operational issue in the (unexpected) case of the cryptographic breakdown of the hash function used to compute HashedRootKey. The current discussion of needing a hash function that is preimage-resistant is good, of course, but some indication of the consequences if a has function becomes bad during the course of use (or a bad hash function is chosen initially) seems to be in order. I also agree with the secdir reviewer that some guidance about how to know that the first trasition is complete would be nice (in the absence of the RFC 4210 transition process), but understand that such guidance is hard to give. From nobody Wed May 29 17:38:03 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0108112010F; Wed, 29 May 2019 17:37:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc6844bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stefan Santesson Message-ID: <155917666691.9144.10382733252232760132@ietfa.amsl.com> Date: Wed, 29 May 2019 17:37:46 -0700 Archived-At: Subject: [lamps] Secdir last call review of draft-ietf-lamps-rfc6844bis-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 00:37:47 -0000 Reviewer: Stefan Santesson Review result: Ready This document is well written and in general I do not have any comment on the content beyond the previous reviews. One thing do come to my mind though. A common aspect of standards documents is that they only are relevant to those who declare compliance to the standard. This document is different as it relies on that all parties (CA:s) are aware of this standard and performs the stipulated checks. In the end I assume that this may affect relying parties and how they determine wether a particular certificate is valid, even if that is not the intention of this standard. I sort of miss a discussion on this in the security considerations section. But that is nothing that should prevent this document from being accepted. From nobody Thu May 30 11:30:29 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27241202A9; Thu, 30 May 2019 11:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.425 X-Spam-Level: X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Sf-UGAVzqfR; Thu, 30 May 2019 11:30:13 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.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 409751202A5; Thu, 30 May 2019 11:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=NewEg7y4m7wxlyEbNmIiaAx4tGw92unt3zPiAoebsOs=; b=DxcxGC2zxGLdXGE55RFs0dJ4Cr JiybSESxB3tpXmvTMLIVos3v5mL0hQGZqKvi5AjxbePqjfB6wAbLNHAUr5eKt2R2n9ymCp5A1B5w3 AjFj5NTBIWQJV54CAz7B2W5XMcbmy8P4x71HTpIc7dNJXIErxd1eVtXB+AMe7GJBALIQ=; Received: ; Thu, 30 May 2019 11:30:10 -0700 To: Stefan Santesson , secdir@ietf.org Cc: spasm@ietf.org, ietf@ietf.org, draft-ietf-lamps-rfc6844bis.all@ietf.org References: <155917666691.9144.10382733252232760132@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: <3f60c58a-7923-d5da-e500-052588a294fb@eff.org> Date: Thu, 30 May 2019 11:30:10 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155917666691.9144.10382733252232760132@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] Secdir last call review of draft-ietf-lamps-rfc6844bis-06 X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 18:30:15 -0000 On 5/29/19 5:37 PM, Stefan Santesson via Datatracker wrote: > A common aspect of standards documents is that they only are relevant to those > who declare compliance to the standard. This document is different as it relies > on that all parties (CA:s) are aware of this standard and performs the > stipulated checks. In practice this has been stipulated for public CAs by the CA/Browser Forum Baseline Requirements since September 2017: https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/. In other words, the CP for this particular community of trust incorporates RFC 6844, making it mandatory. The intent is that once RFC6844bis is standardized, CA/Browser Forum will have a followup ballot incorporating it. From nobody Thu May 30 15:19:13 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B3C1200C1 for ; Thu, 30 May 2019 15:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.425 X-Spam-Level: X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpKKcQzYdtqP for ; Thu, 30 May 2019 15:19:10 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.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 04D05120004 for ; Thu, 30 May 2019 15:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=OnSGYTnaSRrPrOEc5ZGqaJbF8eKb4613p/T2bJqhc4A=; b=Fsnv/DUMDbdXN1+VHiIaqdt/qQ Dzv9dzPVKoO2NVrPohm5HIaLJAn5jaADzkt+sJ1+Rcj9ZugbXPxFTymwNiaDiuERQv+YueVgFsyTv qynzzMaQYyZtUafMqTSh0v7tcHI8VKSTj++c8ZAgZVhN5oBGqR9IIKouXi193M3Fqnfk=; Received: ; Thu, 30 May 2019 15:19:09 -0700 To: spasm@ietf.org References: <155838482753.12864.7318594608163615168.idtracker@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: Date: Thu, 30 May 2019 15:19:08 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155838482753.12864.7318594608163615168.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [lamps] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-lamps-rfc6844bis-06=3A_=28with_COMMENT=29?= X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 22:19:12 -0000 > == COMMENTS == > > -- Section 2.2 -- > > "Domain Name: The label assigned to a node in the Domain Name System." AFAIK > RFC 1034 defines it differently "The domain name of a node is the list of the > labels on the path from the node to the root of the tree" Or are we talking > about different "domain names" ? Thanks, this is good feedback. I adopted language that matches the CA/Browser Forum Baseline Requirements, for better integration there: > Domain Name: The label assigned to a node in the Domain Name System. > Fully-Qualified Domain Name: A Domain Name that includes the labels > of all superior nodes in the Domain Name System. So FQDN matches the "list of labels" definition pretty well. However, looking at this made me realize that this draft says "Domain Name" in a lot of places that should say "FQDN." I'll change all these to FQDN in the next draft. > "Wildcard domain name": it would be interesting to define not only the syntax > but also the semantic do those wildcard domain names. These are defined in https://tools.ietf.org/html/rfc6125#section-6.4.3. > While I am not a security expert, a TLD could add a CAA forcing all its FQDN to > either use the CA defined in the TLD CAA RRset or add a per FQDN CAA (which may > raise the bar for small not-so-managed domains which otherwise could have used > a cheap and easy CA such as letsencrypt). Is it really good to climb the DNS > tree up to the TLD? Just curious. This is sub-optimal, but unfortunately there's no good programmatic way to determine where the TLD begins. For instance "example.co.uk" vs "example.com". The DBOUND WG is working on this problem but it's not solved yet. Since there's an option for subdomains to set their own CAA policy, the negative effects of such a choice by a TLD are not too bad. > I would have preferred a recursive definition rather than an interative > algorithm but this is a matter of taste ;-) I agree, but since it's a matter of taste I decided to err on the side of "similar to previous algorithm" so it's easy for CAs to analyze the differences. From nobody Thu May 30 15:48:35 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DA3120256; Thu, 30 May 2019 15:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.426 X-Spam-Level: X-Spam-Status: No, score=-7.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzQU8DXxDYkU; Thu, 30 May 2019 15:48:21 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.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 1198D120259; Thu, 30 May 2019 15:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=f47U5BuBcfsNnht+LNqITBWDROfRSmMGIF5S2eJA0nM=; b=pGVTmeXItMPfPW+uT3pRKlLBL/ VbZ4syQn/R3XcSjQnBuL39WqDiSVwTZ69b0J/cWhGY1meXYR8juRIbypRIV8DSFE6UeJOQjmJnyOM CN+f8L1UvqXYB3oVQtMFAcLzX5Y8FBUbXFv1jJ2GDGAJzoTdni3aNVyLmRdFlFC5CqSY=; Received: ; Thu, 30 May 2019 15:48:19 -0700 To: Barry Leiba , The IESG Cc: spasm@ietf.org, Russ Housley , draft-ietf-lamps-rfc6844bis@ietf.org, lamps-chairs@ietf.org References: <155903558962.25769.15348770094720924209.idtracker@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: <28595623-ef90-4025-3189-4c52d5714819@eff.org> Date: Thu, 30 May 2019 15:48:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155903558962.25769.15348770094720924209.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2019 22:48:26 -0000 > — Section 4.1 — > > Tag Length: A single octet containing an unsigned integer specifying > the tag length in octets. The tag length MUST be at least 1 and > SHOULD be no more than 15. > > What happens if it’s more than 15? What’s the interoperability issue, and how > would an implementor decide what to do with this requirement? Good point. Removed the <15 suggestion. > > Tags MAY contain US-ASCII characters 'a' through 'z', 'A' through > 'Z', and the numbers 0 through 9. Tags SHOULD NOT contain any other > characters. Matching of tags is case insensitive. > > Why “SHOULD NOT”, rather than “MUST NOT”? Why might my implementation need to > use other characters, and what are the interoperability consequences of doing > so? Changed to MUST NOT. > — Section 4.1.1 — > > Tag: Is a non-zero sequence of US-ASCII letters and numbers in lower > case. > > Make it “non-zero-length”. Done. > > -- Section 4.4 — > > The iodef Property Tag takes a URL as its Property Value. The URL > scheme type determines the method used for reporting: > > I presume that *only* the specified schemes (mailto, http, https) are allowed; > it would help to be explicit about that, lest someone get ideas to use sip or > some such. Done. > > — Section 5.6 — > > In practice, such an attack would be of minimal effect since any > competent competitor that found itself unable to issue certificates > due to lack of support for a Property marked critical SHOULD > investigate the cause and report the reason to the customer. The > customer will thus discover that they had been deceived. > > This doesn’t strike me as a BCP 14 “SHOULD”, but a normal English “should”. Done. From nobody Thu May 30 17:04:36 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F125120113; Thu, 30 May 2019 17:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.425 X-Spam-Level: X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4P1MUuRcMud; Thu, 30 May 2019 17:04:26 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.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 E5F8E120048; Thu, 30 May 2019 17:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ihtDTCuFyQIMAxcR9rxpUMIGlYAFcvEm1uKONrEqqIw=; b=0BT6HLItHdvUgCzu2bzFjb46RE qIvBfybDJ7YiSn4ViJ8Tr/mMnr5zlWB4Xq9seiMla7Gxr/hnKD/xw0gcAVd2Ep6pBNI/q/5oRQtSb mzKfRifbQkG9MOmFk6kYn6xWCd8Y1B6DnjhYV4Nb4eZ5zme2B4iS47m3keboKgiahV7g=; Received: ; Thu, 30 May 2019 17:04:22 -0700 To: Benjamin Kaduk , The IESG Cc: spasm@ietf.org, housley@vigilsec.com, draft-ietf-lamps-rfc6844bis@ietf.org, lamps-chairs@ietf.org References: <155899913320.574.15070810245199939271.idtracker@ietfa.amsl.com> From: Jacob Hoffman-Andrews Message-ID: <66414968-6973-6e07-d3c4-1e03e7692c06@eff.org> Date: Thu, 30 May 2019 17:04:22 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <155899913320.574.15070810245199939271.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 00:04:28 -0000 > I'm not entirely sure why we're going "backwards" from referencing STD13 > to referencing RFCs 1034 and 1035 individually (in the definition of > "Domain Name System"). I'm not actually sure which is preferred here. For instance RFC 5280 cites RFC 1034: https://tools.ietf.org/html/rfc5280#section-11.1 > Section 3 > > RelevantCAASet(domain): > for domain is not ".": > if CAA(domain) is not Empty: > return CAA(domain) > domain = Parent(domain) > return Empty > > It would be nice to get an explicit note about whether this is intended > to be pseudocode, Python code, etc.. Specifically, the "for domain is > not '.'" syntax seems like it might be a more natural fit for a "while" > construct. Updated to mention it's pseudocode. > > Section 4.3 > > issuewild properties MUST be ignored when processing a request for a > Domain Name (that is, not a Wildcard Domain Name). > > I don't wish to revisit well-trodden ground (as I suspect this is), but > note that the provided defitinions in Section 2.2 don't seem to exclude > Wildcard Domain Names from being Domain Names, so that "that is" in the > quoted text is not accurate. (In particular, note that the Wildcard > Domain Name definition says that it is "a Domain Name consisting of > [...]".) You're right that this is well-trodden ground, but looking at this a second time, I realized I had this wrong. A Wildcard Domain Name *is* a Fully-Qualified Domain Name, since an asterisk is a valid DNS label (it's just not in Preferred Name Syntax per RFC 1034). > Section 4.5 > > The critical flag is intended to permit future versions of CAA to > introduce new semantics that MUST be understood for correct > processing of the record, preventing conforming CAs that do not > recognize the new semantics from issuing certificates for the > indicated Domain Names. > > It's not clear to me that the normative "MUST" is best, here. (Is > anyone's behavior being constrained by this statement?) The intent here is to express that future versions would be specifying a "MUST" here. Open to suggestions about how to better say that. > Section 5.1 > > An Issuer MUST NOT issue certificates if doing so would > conflict with the Relevant RRSet, irrespective of whether the > corresponding DNS records are signed. > > I recognize that this is already the security considerations section, > but this requirement introduces its own security considerations, namely > that in cases where CAA responses received by the Issuer can be spoofed, > there is an opportunity for denial of service. Section 5.4 does not > seem to address this additional consideration relating to spoofing. > Section 5.5 perhaps touches on it, but merely talks about "introduction" > of a CAA RR, which may or may not imply the possibility of spoofing to > an arbitrary reader. Added to 5.5 some language about spoofing. > > Use of DNSSEC allows an Issuer to acquire and archive a proof that > they were authorized to issue certificates for the Domain Name. > Verification of such archives MAY be an audit requirement to verify > CAA record processing compliance. Publication of such archives MAY > be a transparency requirement to verify CAA record processing > compliance. > > Neither of these "MAY"s seem to be constraining the parties involved in > this specification, which makes me wonder if they are more appropriate > as ordinary "may"s. Done > > Section 5.4 > > Data cached by third parties MUST NOT be relied on but MAY > be used to support additional anti-spoofing or anti-suppression > controls. > > Is "relied on" meant to imply "relied on as the sole source of DNS CAA > information"? Done > > Section 8 > > Should the registration of the 'CAA' RRtype also be updated to refer to > [this document]? Done From nobody Thu May 30 17:12:23 2019 Return-Path: X-Original-To: spasm@ietf.org Delivered-To: spasm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF545120048; Thu, 30 May 2019 17:12:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: spasm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spasm@ietf.org Message-ID: <155926154166.13404.5611846215833500779@ietfa.amsl.com> Date: Thu, 30 May 2019 17:12:21 -0700 Archived-At: Subject: [lamps] I-D Action: draft-ietf-lamps-rfc6844bis-07.txt X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 00:12:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF. Title : DNS Certification Authority Authorization (CAA) Resource Record Authors : Phillip Hallam-Baker Rob Stradling Jacob Hoffman-Andrews Filename : draft-ietf-lamps-rfc6844bis-07.txt Pages : 18 Date : 2019-05-30 Abstract: The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers. This document obsoletes RFC 6844. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lamps-rfc6844bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-lamps-rfc6844bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lamps-rfc6844bis-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu May 30 17:14:09 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15BF120113 for ; Thu, 30 May 2019 17:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.425 X-Spam-Level: X-Spam-Status: No, score=-7.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsQvfkwgmplI for ; Thu, 30 May 2019 17:14:06 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.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 9643C12016F for ; Thu, 30 May 2019 17:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=D7oXQVjW7Gqas2uydkzHTlN8VBsVKfOSDa0OeV6cKXs=; b=G+PevEYPpAEXfiLg3Bq2w/+3bR Y5A6Cr6rm/duuwOO2O8sLewUYNYngzWUtGw3+doKHlffSPJ2xbvBwrnSGb6KgGFBXMKfbemOG4y5k 6l4+CIymSrLCmhphkoHjJq3l+2BkQgkJq5UWHCtawCJl6yLCs7Rn04F1tpuv2HEM2bgM=; Received: ; Thu, 30 May 2019 17:14:06 -0700 To: SPASM From: Jacob Hoffman-Andrews Message-ID: Date: Thu, 30 May 2019 17:14:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [lamps] New RFC6844bis draft-07 posted X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 00:14:08 -0000 I've posted an updated draft based on IESG review feedback: https://tools.ietf.org/html/draft-ietf-lamps-rfc6844bis-07 Diffs are available here: https://github.com/jsha/caa-simplification/compare/draft-06...draft-07 The most notable change is that references to "Domain Name" have been changed to the more precise "Fully-Qualified Domain Name." From nobody Thu May 30 17:35:40 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E81012016F; Thu, 30 May 2019 17:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 dO8vp5xEinwl; Thu, 30 May 2019 17:35:29 -0700 (PDT) Received: from mail-it1-f170.google.com (mail-it1-f170.google.com [209.85.166.170]) (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 EF6B2120048; Thu, 30 May 2019 17:35:28 -0700 (PDT) Received: by mail-it1-f170.google.com with SMTP id m3so13050590itl.1; Thu, 30 May 2019 17:35:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3aeFrPNMxhdkIB76eDZrd0efFk5ZZOeFZti7cB+VYp4=; b=hH7jU5llipu1D2pB5LC0HpFZMqheyvhayg8R4Du5rhPSgpNtAz8wnzuzJjXljEKB5a 9AwiIFbRn4Zi1BJPiGD/Ddm3x1DWTy4seI9YgPiE0G6SwzrlTND0EcR9EnID9hjHFc3Y tMqbLTO3AMbdHD90cSusPVJ1YLQv9ZAM8qAX75jTtS/iTv71Z47/rovP4WrKNYSZIDTc 2xdriT+VFeKAf62BXH6FXV8dQEaE6U1Jjp+pk5kbw1ugj+Aq9LVjhPNy5VwOpO/WNduC /YeKcQy6+t0GF/uqgv2L9n6ZQhRO/HSZgrL1S8Xpr99YiDCsxzOtFQd1drawcAOy/PVH Cphg== X-Gm-Message-State: APjAAAX2ljv8CJHoGcTzKySutmye0vg5riy1SVbxjznabD/6BugEESo/ IIxxQKjtGjzVsXwBvvsnEae9dtMR4BE1Ir2X9MY= X-Google-Smtp-Source: APXvYqzE2LxN/EWFo95N0tyivSqAPuk3MilC0RVgMBybZRvA5CkmpuHDMQRTjLhiPisBW49D/tNymxR+TuQpD2w1kGw= X-Received: by 2002:a02:b10b:: with SMTP id r11mr4341233jah.140.1559262927756; Thu, 30 May 2019 17:35:27 -0700 (PDT) MIME-Version: 1.0 References: <155903558962.25769.15348770094720924209.idtracker@ietfa.amsl.com> <28595623-ef90-4025-3189-4c52d5714819@eff.org> In-Reply-To: <28595623-ef90-4025-3189-4c52d5714819@eff.org> From: Barry Leiba Date: Fri, 31 May 2019 01:35:16 +0100 Message-ID: To: Jacob Hoffman-Andrews Cc: The IESG , spasm@ietf.org, Russ Housley , draft-ietf-lamps-rfc6844bis@ietf.org, lamps-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [lamps] Barry Leiba's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 00:35:31 -0000 Thanks, Jacob! Barry On Thu, May 30, 2019 at 11:48 PM Jacob Hoffman-Andrews wrote= : > > > > =E2=80=94 Section 4.1 =E2=80=94 > > > > Tag Length: A single octet containing an unsigned integer specifyin= g > > the tag length in octets. The tag length MUST be at least 1 and > > SHOULD be no more than 15. > > > > What happens if it=E2=80=99s more than 15? What=E2=80=99s the interope= rability issue, and how > > would an implementor decide what to do with this requirement? > Good point. Removed the <15 suggestion. > > > > Tags MAY contain US-ASCII characters 'a' through 'z', 'A' through > > 'Z', and the numbers 0 through 9. Tags SHOULD NOT contain any othe= r > > characters. Matching of tags is case insensitive. > > > > Why =E2=80=9CSHOULD NOT=E2=80=9D, rather than =E2=80=9CMUST NOT=E2=80= =9D? Why might my implementation need to > > use other characters, and what are the interoperability consequences of= doing > > so? > Changed to MUST NOT. > > =E2=80=94 Section 4.1.1 =E2=80=94 > > > > Tag: Is a non-zero sequence of US-ASCII letters and numbers in lowe= r > > case. > > > > Make it =E2=80=9Cnon-zero-length=E2=80=9D. > Done. > > > > -- Section 4.4 =E2=80=94 > > > > The iodef Property Tag takes a URL as its Property Value. The URL > > scheme type determines the method used for reporting: > > > > I presume that *only* the specified schemes (mailto, http, https) are a= llowed; > > it would help to be explicit about that, lest someone get ideas to use = sip or > > some such. > Done. > > > > =E2=80=94 Section 5.6 =E2=80=94 > > > > In practice, such an attack would be of minimal effect since any > > competent competitor that found itself unable to issue certificates > > due to lack of support for a Property marked critical SHOULD > > investigate the cause and report the reason to the customer. The > > customer will thus discover that they had been deceived. > > > > This doesn=E2=80=99t strike me as a BCP 14 =E2=80=9CSHOULD=E2=80=9D, bu= t a normal English =E2=80=9Cshould=E2=80=9D. > Done. From nobody Fri May 31 10:03:24 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA69F120086 for ; Fri, 31 May 2019 10:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRXfFAhQdPJz for ; Fri, 31 May 2019 10:03:12 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D61120025 for ; Fri, 31 May 2019 10:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CA43C300AE0 for ; Fri, 31 May 2019 12:43:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id piIODEjE6sww for ; Fri, 31 May 2019 12:43:52 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 46177300471; Fri, 31 May 2019 12:43:52 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> Date: Fri, 31 May 2019 13:03:07 -0400 Cc: IESG , SPASM Content-Transfer-Encoding: quoted-printable Message-Id: <83521276-738B-4298-A36D-B3C04E11A05C@vigilsec.com> References: <155916984601.5535.15415810479866156115.idtracker@ietfa.amsl.com> To: Ben Kaduk X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's Discuss on draft-ietf-lamps-hash-of-root-key-cert-extn-05: (with DISCUSS and COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 17:03:15 -0000 Ben: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > After further reflection, I think we need to resurrect the discussion > sparked by DKG's last-call review. Specifically, in Section 5 when we > consider the case that there is not a directory service/repository > available, we give guidance to "the recipient" and "recipients". But = in > at least some cases, there are two tiers of recipients/relying = parties, > that have different properties, as in the web PKI situation. > Specifically, web server operators rely on root CAs to certify the > certificates that they present to TLS clients. But we also consider = the > TLS clients themselves, which may not have a direct path to receiving > the updated root CA self-signed certificate, and because of the > different ways these different types of recipient rely on root CA > information, the order in which they update can cause breakage. We do > not necessarily need to present a clear solution that will always = avoid > this breakage, but I do think we need to at least discuss the > possibility of such scenarios. >=20 > To consider a concrete case, consider a system with a TLS client = ("A"), > a TLS server ("B"), and the root CA ("C"). C issues (potentially via > intermediates) an end-entity certificate for B, and we consider a case > where A initiates TLS connections to B. Initially, C has the root > CA/key at C1, and is initiating a transition to C2; before the > transition both A and B have C1 in their trusted store. When A = receives > C2, it can perform the requisite validation and add C2 to its trust > store for use potentially validating incoming certificate chains. = When > B receives C2, it can similarly perform the requisite validation and = add > C2 to its trust store, but B's trust store is used for validating > *outgoing* certificate chains, not (just) incoming ones. If B were to > keep C2 in its trust store and construct an outgoing certificate chain > based on C2 (and omitting oldWithNew and newWithOld), before A has > received C2, then the TLS handshake fails! >=20 > If A had access to C2, or to oldWithnew/NewWithOld, then it would = still > be able to validate B's certificate chain, but this document (and RFC > 4210) do not give guidance that B should transmit newWithOld to A, > leaving open this scenario for breakage. >=20 > My current inclination is to add some text to this document = acknowleding > the potential for a chain of relying parties, and recommending that = the > "intermediate parties" in the scenario make newWithOld/oldWithNew = available until > the notAfter time from oldWithNew, but I am of course open to further > discussion/suggestions. I think that the document is fairly clear that there can be some failure = if there is not a repository or directory service. However, while = thinking about this over night, I realized that we could also point to = the the Subject Information Access certificate extension in RFC 5280, = Section 4.2.2.2. The id-ad-caRepository OID is used when the subject is a CA that publishes certificates it issues in a repository. The accessLocation field is defined as a GeneralName, which can take several forms. ... Where the information is available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier and the URI MUST point to either a single DER encoded certificate as specified in [RFC2585] or a collection of certificates in a BER or DER encoded "certs-only" CMS message as specified in [RFC2797]. I am willing to RECOMMEND the inclusion of this extension and posting = the oldWithNew and newWithOld so that they can be fetched using the = "certs-only" (simple PKI response). This format would allow = certificates to be added and removed from the bag of certificates over = time. > Separately, I just want to quickly check that the id-ce-hashOfRootKey > OID has been properly allocated and recorded, as I couldn't find > evidence to indicate that in a quick search. I assume this is the > origin of the CTIA acknowledgment that Alissa mentions, but there's = not > quite enough there to connect the dots. CTIA allocated the OID for the ASN.1 module and the OID for the = certificate extension from their arc. In response to Alissa's comment, = I suggested an additional sentence for the Acknowledgements to make this = clear. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Section 1.1 >=20 > Please use the boilerplate from RFC 8174 (yes, I read the shepherd = writeup). Already fixed in my edit buffer. > Section 1.2 >=20 > side note: this claim about "always encoded with DER" seems a bit > optimistic unless scoped down to a specific context. X.509 and RFC 5280 require the DER encoding for the signature = computation and the signature validation. If someone uses a different = encoding somewhere along the way, it needs to be put back in DER form = for the signature to validate. How about: Certificates [RFC5280] use ASN.1 [X680]; Distinguished Encoding Rules (DER) [X690] are REQUIRED for certificate signing and validation. > Section 5 >=20 > After issuing the oldWithNew and newWithOld certificates, the Root = CA > MUST stop using the old private key to sign certificates. >=20 > Isn't this only relevant for newWithOld? We don't need to use the old > private key to sign certificates to make a certification of the old = key > signed by the new key. This is a statement about when to stop using the old private key. But, = indeed, you are correct: After issuing the newWithOld certificate, the Root CA MUST stop using the old private key to sign certificates. > Changing names from one generation to another can lead to confusion > when reviewing the history of a trust anchor store. To assist with > such review, a recipient MAY create an audit entry to capture the = old > and replacement self-signed certificates. >=20 > It seems like there may be non-name changes that might also cause > confusion (or worse); do we want to mention this possibility and/or = the > recipient's duty to check for unexpected changes? This was a recommendation from DKC in the thread that you reference in = your DISCUSS comments. I do not know of any relying part software that = keeps the audit log of changes to the trust store. Many software update = programs, for example, update the trust anchor store without creating = such an audit. I am not sure that building further on this concept is = desirable. > Section 6 >=20 > I think some explicit guidance is needed about there being a critical > operational issue in the (unexpected) case of the cryptographic > breakdown of the hash function used to compute HashedRootKey. The > current discussion of needing a hash function that is = preimage-resistant > is good, of course, but some indication of the consequences if a has > function becomes bad during the course of use (or a bad hash function = is > chosen initially) seems to be in order. How about adding this sentence to the end of that paragraph: If the employed hash function is broken after the Root CA publishes the self-signed certificate with the HashOfRootKey certificate extension, an attacker would be able to trick the recipient into installing the incorrect next generation certificate in the trust anchor store. > I also agree with the secdir reviewer that some guidance about how to > know that the first trasition is complete would be nice (in the = absence > of the RFC 4210 transition process), but understand that such guidance > is hard to give. I do not have great advice, but there is a hint: Queries for the CRLs associated with certificates that are subordinate to the self-signed certificate can give some indication for the number of relying parties that are still actively using the self-signed certificates. Russ= From nobody Fri May 31 12:08:27 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F071203E7 for ; Fri, 31 May 2019 12:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6tl1Mk5CCFu for ; Fri, 31 May 2019 12:08:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05771203E6 for ; Fri, 31 May 2019 12:08:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id DC57F38185; Fri, 31 May 2019 15:07:12 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F31E8E0A; Fri, 31 May 2019 15:08:19 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F1AD4DF2; Fri, 31 May 2019 15:08:19 -0400 (EDT) From: Michael Richardson To: Tomas Gustavsson cc: spasm@ietf.org In-Reply-To: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 19:08:26 -0000 --=-=-= Content-Type: text/plain First, thank you for providing an excellent summary as to why one might use CMP rather than EST. Tomas Gustavsson wrote: > EST and CMP have fundamentally different security aspects, making them > suitable for different use cases. It's not one of the other, both are > needed due to the different ways of working: > - EST uses the communication layer (TLS) for security, it is simple and > easy, but depends on TLS (for good and for bad, mostly for good where > this approach is suitable) > - CMP uses message security and is independent of the communication > layer, the messages are self-sufficient (for good and for bad, mostly > for good where this approach is suitable) > EST and CMP are not competing standard, but very much complementary and > as product implementor we like them both. ... > Unfortunately CMP (RFC4210) is more of a framework and solutions are not > interoperable because they use fields in different ways. Profiling is > needed. The best profiling of CMP that I have seen so far is 3GPP > 33.310 This is why I have ignored CMP. > There is profiling going on for EST, see EST over Secure CoAP for > example. https://tools.ietf.org/html/draft-ietf-ace-coap-est-11 As an author of ace-coap-esp, I would not really call it a profile... We are really changing the transport and addressing, but I acknowledge that maybe it's a profile decision as to what we are not translating. > IEC 62351 is a for purchase standard, and those rarely get high traction > except for their limited scope/vertical. Amen Brother! Based upon your comments, I will change my view, and offer support for lightweight CMP. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzxe6MACgkQgItw+93Q 3WX+yAf8CqtTTEEyd3L7DcbBmcWwep5lb2g3FddOCcCSeZBBajJGKCSQSuvNHouH hlTTJ+MJGEzlF9BUoCaPwzJ80KPCnNM7N66wKQtomgrRUzv/yCdiLUdlcO66BIQD 6UNIdgaxlWXUft1X2KVh5ta2Yt8ADILj+eAwPgYK4IXVXw4GlSAHGt99ANUNZA9h OJOvQqJ7ePNUrDYdWu+Xa8A3Qn0yBkLGpJ35ynzf9gLQf/kYUFDw5WcEi1ms5+4Z GK6hwviyty9rlrDFnjk8uOn8Kelir0T/KSX8wt6Eb4sHhPGCJpQuNEVZYPLshudR uWYa2xShaQYp3S1RFcSnvOE0WrRg4g== =u6Y8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 31 12:12:12 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05911203FD for ; Fri, 31 May 2019 12:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEMBGl1kpFJ9 for ; Fri, 31 May 2019 12:12:08 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A6B1203F7 for ; Fri, 31 May 2019 12:12:05 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id ECF7A38187; Fri, 31 May 2019 15:10:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1D058E0A; Fri, 31 May 2019 15:12:04 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1BA77DF2; Fri, 31 May 2019 15:12:04 -0400 (EDT) From: Michael Richardson To: "Peylo\, Martin \(Nokia - FI\/Espoo\)" cc: "spasm\@ietf.org" In-Reply-To: References: <29FAEBF1-2D67-469F-BE78-AF58F78D055E@vigilsec.com> <17374.1559083024@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [lamps] Support for working on the lightweight CMP profile X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2019 19:12:11 -0000 --=-=-= Content-Type: text/plain Peylo, Martin (Nokia - FI/Espoo) wrote: > One should note that the subject of this email seems to be somewhat > misleading as it is overly limiting the scope. I expect that besides > clarifications for e.g. RA-CA communications, the upcoming work will > also include a refresh of mandatory algorithms (bye bye SHA-1). While > both of those will certainly be beneficial also for the lightweight CMP > on the interface to EEs, it will also have positive influence beyond > the "lightweight CMP" scope. I think that updating algorithms almost goes without saying, but it's good you said it. >> Plus we have a bunch of proprietary RESTful interfaces to CAs. > As they are proprietary, they seem to be somewhat out of IETF scope and > interoperability might not have been your focus when you were creating > those? The point is, if I have to support a proprietary interface to some CA, is there an advantage to also supporting a standard lightweight CMP if talking to the CA vendor still requires the proprietary RESTful interface. I am expected one or two of those to become defacto specifications, the way the AWS EC2 API did. (ps: I am the author of a Registration Authority product) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlzxfIMACgkQgItw+93Q 3WUGiQf9H9RIuPc+eiNFwV8zVWxIofHke6Q1H+Y/EGUAEDljqLQA9lBd9MzsQmn6 kPt0sqUcxtIh1hkje5kmchNk3kr2zPbNJrOYdZ27MtaiOaMvL26hQosMfmyoEc0v Aho3VjaPvec5erJ/hbIaJdCBMj407CZtHYaO/hDlVsBOgQdewr6mHDkNGh+nkGqP /YnurHn1VzSTXq8wVmlxZb2FaP2pAlf5DfHXFAa8f8PwaTDjiW6/aU9/8pitrL13 inRNoy3Tf3AQtBkvDA00VP09oUJKr+76SAzGBL61SeWnAvXwhTFP/8tGelCuwxw6 bE+2Icwy82EQu0oW5WtaDxeWHsCaKQ== =IIaU -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 31 23:08:41 2019 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E7A1200CC; Fri, 31 May 2019 23:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SEuf2A0se6a; Fri, 31 May 2019 23:08:30 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5F112004D; Fri, 31 May 2019 23:08:29 -0700 (PDT) Received: from prolepsis.kaduk.org (c-24-16-119-19.hsd1.wa.comcast.net [24.16.119.19]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5168LMc002283 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 1 Jun 2019 02:08:24 -0400 Date: Fri, 31 May 2019 23:08:21 -0700 From: Benjamin Kaduk To: Jacob Hoffman-Andrews Cc: The IESG , spasm@ietf.org, housley@vigilsec.com, draft-ietf-lamps-rfc6844bis@ietf.org, lamps-chairs@ietf.org Message-ID: <20190601060820.GA27402@prolepsis.kaduk.org> References: <155899913320.574.15070810245199939271.idtracker@ietfa.amsl.com> <66414968-6973-6e07-d3c4-1e03e7692c06@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66414968-6973-6e07-d3c4-1e03e7692c06@eff.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [lamps] Benjamin Kaduk's No Objection on draft-ietf-lamps-rfc6844bis-06: (with COMMENT) X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 06:08:32 -0000 On Thu, May 30, 2019 at 05:04:22PM -0700, Jacob Hoffman-Andrews wrote: > > > I'm not entirely sure why we're going "backwards" from referencing STD13 > > to referencing RFCs 1034 and 1035 individually (in the definition of > > "Domain Name System"). > I'm not actually sure which is preferred here. For instance RFC 5280 cites > RFC 1034: https://tools.ietf.org/html/rfc5280#section-11.1 To be honest, I am not actually sure either (in that I can't point to any IETF-consensus document backing my position), but the general idea of STD numbers is that they refer to the whole standard, even if that changes over time (e.g., by adding new documents), and is a way to recognize the effort that has gone in to advancing documents to full Internet (not Proposed) Standard status. > > > Section 3 > > > > RelevantCAASet(domain): > > for domain is not ".": > > if CAA(domain) is not Empty: > > return CAA(domain) > > domain = Parent(domain) > > return Empty > > > > It would be nice to get an explicit note about whether this is intended > > to be pseudocode, Python code, etc.. Specifically, the "for domain is > > not '.'" syntax seems like it might be a more natural fit for a "while" > > construct. > Updated to mention it's pseudocode. Thanks. (Though in general I would prefer real code to pseudocode, since then it can be tested and such.) > > > > Section 4.3 > > > > issuewild properties MUST be ignored when processing a request for a > > Domain Name (that is, not a Wildcard Domain Name). > > > > I don't wish to revisit well-trodden ground (as I suspect this is), but > > note that the provided defitinions in Section 2.2 don't seem to exclude > > Wildcard Domain Names from being Domain Names, so that "that is" in the > > quoted text is not accurate. (In particular, note that the Wildcard > > Domain Name definition says that it is "a Domain Name consisting of > > [...]".) > > You're right that this is well-trodden ground, but looking at this a second > time, I realized I had this wrong. A Wildcard Domain Name *is* a > Fully-Qualified Domain Name, since an asterisk is a valid DNS label (it's > just not in Preferred Name Syntax per RFC 1034). > > Section 4.5 > > > > The critical flag is intended to permit future versions of CAA to > > introduce new semantics that MUST be understood for correct > > processing of the record, preventing conforming CAs that do not > > recognize the new semantics from issuing certificates for the > > indicated Domain Names. > > > > It's not clear to me that the normative "MUST" is best, here. (Is > > anyone's behavior being constrained by this statement?) > The intent here is to express that future versions would be specifying a > "MUST" here. Open to suggestions about how to better say that. AFAICT the RFC 8174 lowercase "must" fulfils that role. > > Section 5.1 > > > > An Issuer MUST NOT issue certificates if doing so would > > conflict with the Relevant RRSet, irrespective of whether the > > corresponding DNS records are signed. > > > > I recognize that this is already the security considerations section, > > but this requirement introduces its own security considerations, namely > > that in cases where CAA responses received by the Issuer can be spoofed, > > there is an opportunity for denial of service. Section 5.4 does not > > seem to address this additional consideration relating to spoofing. > > Section 5.5 perhaps touches on it, but merely talks about "introduction" > > of a CAA RR, which may or may not imply the possibility of spoofing to > > an arbitrary reader. > Added to 5.5 some language about spoofing. > > > > Use of DNSSEC allows an Issuer to acquire and archive a proof that > > they were authorized to issue certificates for the Domain Name. > > Verification of such archives MAY be an audit requirement to verify > > CAA record processing compliance. Publication of such archives MAY > > be a transparency requirement to verify CAA record processing > > compliance. > > > > Neither of these "MAY"s seem to be constraining the parties involved in > > this specification, which makes me wonder if they are more appropriate > > as ordinary "may"s. > Done > > > > Section 5.4 > > > > Data cached by third parties MUST NOT be relied on but MAY > > be used to support additional anti-spoofing or anti-suppression > > controls. > > > > Is "relied on" meant to imply "relied on as the sole source of DNS CAA > > information"? > Done > > > > Section 8 > > > > Should the registration of the 'CAA' RRtype also be updated to refer to > > [this document]? > Done Thanks for all of these! -Ben