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