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

"Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com> Thu, 09 May 2019 17:22 UTC

Return-Path: <hendrik.brockhaus@siemens.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 069DB12003E for <spasm@ietfa.amsl.com>; 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 <spasm@ietfa.amsl.com>; 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 <spasm@ietf.org>; 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" <hendrik.brockhaus@siemens.com>
To: "spasm@ietf.org" <spasm@ietf.org>, "Peylo, Martin (Nokia - FI/Espoo)" <martin.peylo@nokia.com>, "Dr. Pala" <director@openca.org>
CC: Jim Schaad <ietf@augustcellars.com>, "steffen.fries@siemens.com" <steffen.fries@siemens.com>, Russ Housley <housley@vigilsec.com>
Thread-Topic: Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)
Thread-Index: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAACRFEAAODOVoA==
Date: Thu, 09 May 2019 17:22:22 +0000
Message-ID: <AM0PR10MB24029AF6D82DDE3E81347F04FE330@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB24028210BCE560C64195A74EFE320@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM> <MWHPR11MB1838E6295E39B04C0591DC28C9320@MWHPR11MB1838.namprd11.prod.outlook.com> <HE1PR0701MB244401CFEC4F4006C7FD443D9B320@HE1PR0701MB2444.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR0701MB244401CFEC4F4006C7FD443D9B320@HE1PR0701MB2444.eurprd07.prod.outlook.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: [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: <AM0PR10MB2817FB7932E0AD72B4B4A58EFE330@AM0PR10MB2817.EURPRD10.PROD.OUTLOOK.COM>
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: <https://mailarchive.ietf.org/arch/msg/spasm/pZBFJWqPNZjldLbRXLCu1gqT5OI>
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: Thu, 09 May 2019 17:22:41 -0000

Hi Martin, hi Max,

thank you for your support.

Martin mentioned his Mbed(tm) based CMP implementation. This was a great starting point for us to extend the implementation to support further use cases 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) <martin.peylo@nokia.com>
Gesendet: Mittwoch, 8. Mai 2019 16:54
An: Panos Kampanakis (pkampana) <pkampana@cisco.com>; 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,

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<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnokia%2FCMPclient-embedded-lib&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7C2a216d814ab94c27e3d508d6d3c50e31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929240648653611&sdata=6yPJdsOGjQgr%2BjT1EFhsuR5DnvGq2qxkW5L7KDTjSd8%3D&reserved=0>

From: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> On Behalf Of Panos Kampanakis (pkampana)
Sent: Wednesday, May 8, 2019 5:00 PM
To: spasm@ietf.org<mailto:spasm@ietf.org>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; Brockhaus, Hendrik <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>>
Cc: Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>>; steffen.fries@siemens.com<mailto: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%7C2a216d814ab94c27e3d508d6d3c50e31%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929240648653611&sdata=oVX2KXkN%2F35Akt%2F6ShQIh5WO8UWB6jUIszdceVpEOYk%3D&reserved=0>