Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)

"Peylo, Martin (Nokia - FI/Espoo)" <martin.peylo@nokia.com> Wed, 08 May 2019 14:54 UTC

Return-Path: <martin.peylo@nokia.com>
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 <spasm@ietfa.amsl.com>; 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 <spasm@ietfa.amsl.com>; 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 <spasm@ietf.org>; 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)" <martin.peylo@nokia.com>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "spasm@ietf.org" <spasm@ietf.org>, Russ Housley <housley@vigilsec.com>, "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
CC: Jim Schaad <ietf@augustcellars.com>, "steffen.fries@siemens.com" <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, 08 May 2019 14:53:59 +0000
Message-ID: <HE1PR0701MB244401CFEC4F4006C7FD443D9B320@HE1PR0701MB2444.eurprd07.prod.outlook.com>
References: <AM0PR10MB24028210BCE560C64195A74EFE320@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM> <MWHPR11MB1838E6295E39B04C0591DC28C9320@MWHPR11MB1838.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB1838E6295E39B04C0591DC28C9320@MWHPR11MB1838.namprd11.prod.outlook.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.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: <HE1PR0701MB24736E75657210353330C4C09B320@HE1PR0701MB2473.eurprd07.prod.outlook.com>
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: <https://mailarchive.ietf.org/arch/msg/spasm/d6BXsUsHPDN-fpbMF0j6TVn7H5Q>
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." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2019 14:54:15 -0000

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 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 for implementing with wide interworking - there are e.g. multiple meaningful ways to implement RA-CA communications. So, clear CMP profiles will be a valuable 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 caters very well for the needs of RA-CA communications, and there are many scenarios where PKIs for constrained devices benefit from utilizing RAs. So, also a clear profile for RA-CA communication would certainly be a benefit the constrained-device world, even if it is not directly 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 client [1] for Mbed(tm) 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 of 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>; Brockhaus, 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)


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<mailto:spasm-bounces@ietf.org>> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 5:10 AM
To: spasm@ietf.org<mailto:spasm@ietf.org>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>
Cc: Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>>; steffen.fries@siemens..com<mailto: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<mailto:housley@vigilsec.com>>
Gesendet: Mittwoch, 8. Mai 2019 02:18
An: Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>>
Cc: spasm@ietf.org<mailto:spasm@ietf.org>; Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>>; Fries, Steffen (CT RDA ITS) <steffen.fries@siemens.com<mailto: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<mailto: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<mailto:Spasm@ietf.org>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cb2dc4e66b2644d53d64308d6d34aa72c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636928715140199163&sdata=vbsWP%2FRwxnN6qgWKB2Qbq7aC5CFobDEJCTqJOBkSIJk%3D&reserved=0>