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> Fri, 10 May 2019 06:48 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 B80DD12018F for <spasm@ietfa.amsl.com>; 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 <spasm@ietfa.amsl.com>; 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 <spasm@ietf.org>; 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" <hendrik.brockhaus@siemens.com>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "spasm@ietf.org" <spasm@ietf.org>
CC: Jim Schaad <ietf@augustcellars.com>, Russ Housley <housley@vigilsec.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: AdUFfDdARgDJEG61S0aIn5X7GJC6HQAKDYZwAAIqrYAAGMXOoAA62/yg
Date: Fri, 10 May 2019 06:47:09 +0000
Message-ID: <AM0PR10MB24028A1C7D87235BBA51E39EFE0C0@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB24028210BCE560C64195A74EFE320@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM> <MWHPR11MB1838E6295E39B04C0591DC28C9320@MWHPR11MB1838.namprd11.prod.outlook.com> <AM0PR10MB24028EE38E0E50BA6B30BC05FE320@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM> <MWHPR11MB18382E8686BF5B7396670A94C9330@MWHPR11MB1838.namprd11.prod.outlook.com>
In-Reply-To: <MWHPR11MB18382E8686BF5B7396670A94C9330@MWHPR11MB1838.namprd11.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: [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: <AM0PR10MB1891CA19BEF8947F07535E5BFE0C0@AM0PR10MB1891.EURPRD10.PROD.OUTLOOK.COM>
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: <https://mailarchive.ietf.org/arch/msg/spasm/ZAs0M8uMCG1K3JVbLhejc9v6LYk>
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: Fri, 10 May 2019 06:48:17 -0000

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@siemens.com>; spasm@ietf.org
Cc: Jim Schaad <ietf@augustcellars.com>; Russ Housley <housley@vigilsec.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,
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 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 environment with multiple hops.
Another question.  Why is this a LAMPS item? Creating a CMP profile that applies to a specific 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 usecase. Why should this item be part of the LAMPS charter and not ISO ICS or IEC that seem more natural homes?
[Bro] Agreed! We target a generic lightweight profile for CMP which we would like to apply to industry. Similar profiles have already been specified by 3GPP for telecommunication. We write the I-D independent from any vertical, just specifying the certificate management use cases more precisely.
As described in my initial mail, there is some very limited update of CMP needed 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 LAMPS as maintainer of PKIX RFCs.
As the CMP profile aims to be 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.

Thanks,
Panos


From: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> On Behalf Of Brockhaus, Hendrik
Sent: Wednesday, May 08, 2019 11:02 AM
To: Panos Kampanakis (pkampana) <pkampana@cisco.com<mailto:pkampana@cisco.com>>; spasm@ietf.org<mailto:spasm@ietf.org>
Cc: Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.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 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<mailto:pkampana@cisco.com>>
Gesendet: Mittwoch, 8. Mai 2019 16:00
An: spasm@ietf.org<mailto:spasm@ietf.org>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; Brockhaus, Hendrik (CT RDA ITS SEA-DE) <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>>
Cc: 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: 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%7C13a5dce99f8142fc6dfb08d6d4aff708%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636930249563542771&sdata=QnmjZmc5c8kaM9a2RsMsWr7zsRrl9pR7EdPch%2B0q6ac%3D&reserved=0>