[lamps] Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile

"Fries, Steffen" <steffen.fries@siemens.com> Tue, 02 April 2019 05:12 UTC

Return-Path: <steffen.fries@siemens.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5BA9D120086 for <spasm@ietfa.amsl.com>; Mon, 1 Apr 2019 22:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9NDLBpRWK7Yh for <spasm@ietfa.amsl.com>; Mon, 1 Apr 2019 22:12:20 -0700 (PDT)
Received: from gecko.sbs.de (gecko.sbs.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E44B12001E for <spasm@ietf.org>; Mon, 1 Apr 2019 22:12:20 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de []) by gecko.sbs.de (8.15.2/8.15.2) with ESMTPS id x325CHet006104 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <spasm@ietf.org>; Tue, 2 Apr 2019 07:12:17 +0200
Received: from DEFTHW99ERNMSX.ww902.siemens.net (defthw99ernmsx.ww902.siemens.net []) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id x325CHlo020123 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <spasm@ietf.org>; Tue, 2 Apr 2019 07:12:17 +0200
Received: from DENBGAT9ER2MSX.ww902.siemens.net ( by DEFTHW99ERNMSX.ww902.siemens.net ( with Microsoft SMTP Server (TLS) id 14.3.435.0; Tue, 2 Apr 2019 07:12:18 +0200
Received: from DENBGAT9EJ5MSX.ww902.siemens.net ([]) by DENBGAT9ER2MSX.ww902.siemens.net ([]) with mapi id 14.03.0435.000; Tue, 2 Apr 2019 07:12:17 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: "spasm@ietf.org" <spasm@ietf.org>
Thread-Topic: Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile
Thread-Index: AdTpEqMJe7nRixUIQJ2pi62nhzW52w==
Date: Tue, 2 Apr 2019 05:12:15 +0000
Message-ID: <BF6D964D-BE83-430A-97CD-48BE51CA1BBD@siemens.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1992CF699A457E48975C62D10C45921A@internal.siemens.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Y22dwA5ClWOjS3cmbzTJ1pUbqR4>
Subject: [lamps] Seeking guidance on proceeding with question from IETF-104 presentation 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: Tue, 02 Apr 2019 05:12:25 -0000


during the LAMPS session in IETF-104 we presented a draft for a lightweight industrial CMP profile. The document as such bases on CMP and targets to simplify the very versatile CMP. 

During the presentation we have been asked to also talk to the ACE WG chair regarding potential interest in this work, as it was not sure if LAMPS is the right home. I talked to Jim Schaad and as we only work on CMP directly, not with the transport nor specific considerations for constraint devices, ACE may not be the right home. Also, Jim was asking if the draft needs to be a standards track RFC and thus be adopted in a WG. An alternative approach could also be an independent submission. To make this decision, we need some guidance. 

For this, let me enumerate the main points we addressed in the draft:
- Generally Section 1.4 enlists the exceptions from the mandatory CMP Profile as defined in RFC4210 Appendix D:
 o  signature-based protection is the default protection; initial transactions may also use HMAC,
 o  certification of a second key pair within the same transaction is not supported,
 o  proof-of-possession (POPO) with self-signature of the certTemplate according to [RFC4211] section 4.1 clause 3 is the only supported POPO  method,
 o  confirmation of newly enrolled certificates may be omitted, and especially
 o  all transactions consist of request-response message pairs originating at the end entity (EE), i.e., announcement messages are omitted.
- In section 4.1.5 the proceeding of central key generation needed extensions at least for ECC key pairs.
- In section 4.4.1 the RootCAUpdate is specified as request-response transaction and differs from the announcement message as specified in RFC4210 section 4.4 and Appendix E.
- In section 5 the new Extended Key Usages id-kp-cmpRA is introduced to indicate that a key pair is entitled to be used by an LRA/RA for signature-based protection of a CMP message.
- Generally further topics to clarify CMP or CRMF may come up during WG review.

Based on this list, are these point to be handled as profiling of the base protocol or are they rather seen as technical change/enhancement? 
My understanding is that for profiling an independent RFC would be fine, as the base spec can be normatively referenced by other standards. In this case the CMP profile document can be informational. 
If some of the points listed qualify rather for technical changes of the base protocol, my understanding is that we need to find a home for the draft and target the standard track. @Jim, I hope my conclusion based on our conversation is right.

Regarding interest in the resulting RFC there is work ongoing in ANIMA WG and EAP WG, that can directly leverage the lightweight CMP.

In either case your view is appreciated.

Best regards