Re: [lamps] Proposed Re-Chartering Text for CMP updates and lightweight profile (RE: Follow-up on lightweight CMP profile)
"Dr. Pala" <director@openca.org> Wed, 08 May 2019 23:12 UTC
Return-Path: <director@openca.org>
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 <spasm@ietfa.amsl.com>; 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 <spasm@ietfa.amsl.com>; 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 <spasm@ietf.org>; 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 <spasm@ietf.org>; 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 <spasm@ietf.org>; 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 <spasm@ietf.org>; Wed, 8 May 2019 19:12:19 -0400 (EDT)
To: spasm@ietf.org
References: <AM0PR10MB24028210BCE560C64195A74EFE320@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM> <MWHPR11MB1838E6295E39B04C0591DC28C9320@MWHPR11MB1838.namprd11.prod.outlook.com> <AM0PR10MB24028EE38E0E50BA6B30BC05FE320@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM>
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <cfa98f1a-9b7e-7618-491e-00cfdecdb766@openca.org>
Date: Wed, 08 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: <AM0PR10MB24028EE38E0E50BA6B30BC05FE320@AM0PR10MB2402.EURPRD10.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative; boundary="------------6D52ED8AA17D9AC797A7DD10"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/RmjM-NDOJ_vMkJUa4jWXdWPBHmw>
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 23:12:35 -0000
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 <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%7C826a1c2e978d47ab1dea08d6d3bd8a02%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636929208355269935&sdata=KYX7htjTVg8Eppn8PrwnN0kVojKPnYpCvUpuiI8bn58%3D&reserved=0> > > > _______________________________________________ > Spasm mailing list > Spasm@ietf.org > https://www.ietf.org/mailman/listinfo/spasm -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo
- [lamps] Proposed Re-Chartering Text for CMP updat… Brockhaus, Hendrik
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Panos Kampanakis (pkampana)
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Peylo, Martin (Nokia - FI/Espoo)
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Brockhaus, Hendrik
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Dr. Pala
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Brockhaus, Hendrik
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Panos Kampanakis (pkampana)
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Panos Kampanakis (pkampana)
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Brockhaus, Hendrik
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Brockhaus, Hendrik
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Panos Kampanakis (pkampana)
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Brockhaus, Hendrik
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Brockhaus, Hendrik
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Fries, Steffen
- Re: [lamps] Proposed Re-Chartering Text for CMP u… Brockhaus, Hendrik
- [lamps] Support for working on the lightweight CM… Russ Housley
- Re: [lamps] Support for working on the lightweigh… Tomas Gustavsson
- Re: [lamps] Support for working on the lightweigh… Peylo, Martin (Nokia - FI/Espoo)
- Re: [lamps] Support for working on the lightweigh… Brockhaus, Hendrik
- Re: [lamps] Support for working on the lightweigh… Panos Kampanakis (pkampana)
- Re: [lamps] Support for working on the lightweigh… Michael Richardson
- Re: [lamps] Support for working on the lightweigh… Fries, Steffen
- Re: [lamps] Support for working on the lightweigh… Tomas Gustavsson
- Re: [lamps] Support for working on the lightweigh… Peylo, Martin (Nokia - FI/Espoo)
- Re: [lamps] Support for working on the lightweigh… Michael Richardson
- Re: [lamps] Support for working on the lightweigh… Michael Richardson
- Re: [lamps] Support for working on the lightweigh… Tomas Gustavsson
- [lamps] Interest to standardize PKI REST APIs? Tomas Gustavsson
- Re: [lamps] Support for working on the lightweigh… Brockhaus, Hendrik
- Re: [lamps] Interest to standardize PKI REST APIs? Brockhaus, Hendrik
- Re: [lamps] Interest to standardize PKI REST APIs? Michael Richardson
- Re: [lamps] Interest to standardize PKI REST APIs? Tomas Gustavsson
- Re: [lamps] Interest to standardize PKI REST APIs? Salz, Rich
- Re: [lamps] Interest to standardize PKI REST APIs? Tomas Gustavsson
- Re: [lamps] Interest to standardize PKI REST APIs? Salz, Rich
- Re: [lamps] Interest to standardize PKI REST APIs? Tomas Gustavsson
- Re: [lamps] Interest to standardize PKI REST APIs? Salz, Rich
- Re: [lamps] Interest to standardize PKI REST APIs? Tomas Gustavsson
- Re: [lamps] Interest to standardize PKI REST APIs? Brockhaus, Hendrik
- Re: [lamps] Interest to standardize PKI REST APIs? Tomas Gustavsson
- Re: [lamps] Interest to standardize PKI REST APIs? Brockhaus, Hendrik
- Re: [lamps] Interest to standardize PKI REST APIs? Salz, Rich
- Re: [lamps] Interest to standardize PKI REST APIs? Dr. Pala
- Re: [lamps] Interest to standardize PKI REST APIs? Tomas Gustavsson