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

"Fries, Steffen" <> Wed, 03 April 2019 19:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 954E1120180 for <>; Wed, 3 Apr 2019 12:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ELXC_jLf7kKG for <>; Wed, 3 Apr 2019 12:06:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7B64E120167 for <>; Wed, 3 Apr 2019 12:06:02 -0700 (PDT)
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x33J5tYV021981 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Apr 2019 21:05:55 +0200
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x33J5siD019262 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 3 Apr 2019 21:05:55 +0200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.435.0; Wed, 3 Apr 2019 21:05:54 +0200
Received: from ([]) by ([]) with mapi id 14.03.0435.000; Wed, 3 Apr 2019 21:05:53 +0200
From: "Fries, Steffen" <>
To: Jim Schaad <>
CC: "" <>
Thread-Topic: [lamps] Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile
Thread-Index: AdTpEqMJe7nRixUIQJ2pi62nhzW52wAYoVsAACq2+aAABn4sAAAFkTzD
Date: Wed, 3 Apr 2019 19:05:52 +0000
Message-ID: <>
References: <> <027301d4e985$efd03970$cf70ac50$> <>, <001a01d4ea4a$c27453b0$475cfb10$>
In-Reply-To: <001a01d4ea4a$c27453b0$475cfb10$>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [lamps] Seeking guidance on proceeding with question from IETF-104 presentation on lightweight CMP profile
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Apr 2019 19:06:06 -0000

> On 3. Apr 2019, at 20:26, Jim Schaad <> wrote:
>> -----Original Message-----
>> From: Spasm <> On Behalf Of Fries, Steffen
>> Sent: Wednesday, April 3, 2019 9:12 AM
>> To: Jim Schaad <>om>;
>> Subject: Re: [lamps] Seeking guidance on proceeding with question from
>> IETF-104 presentation on lightweight CMP profile
>> Hi Jim,
>>> This is a quick walk through what you have below.  It would have been
>>> helpful to have pointers to the sections/bullet points where things are
>> meant to be modified.
>> First of all, thank you for the walk through. I made some comments to your
>> questions.
>>>> Hi,
>>>> 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,
>>> Depending on what is being proven this is reasonable.  I would
>>> consider this to be profiling
>>>> o  certification of a second key pair within the same transaction is
>>>> not
>>> supported,
>>> I would consider this to be profiling
>>>> 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,
>>> I would consider this to be profiling
>>>> o  confirmation of newly enrolled certificates may be omitted, and
>>> especially
>>> I would consider this to be profiling
>>>> o  all transactions consist of request-response message pairs
>>>> originating
>>> at the end entity (EE), i.e.,  announcement messages are omitted.
>>> I would consider this to be profiling
>>>> - In section 4.1.5 the proceeding of central key generation needed
>>>> extensions at least for ECC key pairs.
>>> Not sure what you think falls here and the document is not forth coming.
>>> This may have already been done.
>> Our understanding was that the current approach in RFC 4210 requires at
>> least some support for RSA even if the generated key pair is ECDSA. This
> is
>> due to the statement for encrypting the private key when sending the
>> generated material back to the client. Here, the encryption key is to be
>> encrypted with a short term asymmetric key of the client.
> Profiling to use EncryptedKey rather than EncryptedValue would deal with
> this issue.  It would also provide all of the other good things that might
> show up in the future such as quantum crypto as they would be done for the
> CMS work.  This would not change any existing implementations that are still
> RSA.

That is a nice approach not requiring own additions and using what is already there. Much appreciated.

>>>> - 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.
>>> Depending on how this is done, it will require an update of RFC 4211.
>>> I believe that this means it must be an IETF consensus document and may
>> need to be standards track.
>> The intention here was to avoid the announce messages for the RootCA
>> update completely to better support application in constraint devices,
> which
>> may be temporarily offline or my not feature a server part listening for
>> announce messages. Using a request response allows the client to simply
> ask
>> for an update.
>> Why do you think this will influence also RFC 4211?
> Typo - I think of RFC4210 and RFC 4211 as being together and had both open.
> I meant to type RFC 4210.
> I am not sure how much this is needed depending on how often this is used
> and why you think this is needed.  If you have a directory or similar then
> pointers to where they can be found.
We just wanted to avoid that a client has to listen for the announce messages. Pointing to a directory would then be out of the definition from CMP and rather a client side configuration? Yes, this could be done. Alternatively the CMP request/response may be used.
>>>> - 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.
>>> This can be considered to be a profile.
>>>> - 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.
>>> Have either of these groups expressed any active interest in this work?
>>> This is not something that EAP would normally be looking at as far as
>>> I know as they normally consider the act of setting up the EAP
> credentials
>> to be a "Not My Problem" space.
>> Both groups are not active regarding CMP adaptation to my knowledge. But
>> there are documents discussed (currently individual submissions and not WG
>> items), which can leverage a lightweight CMP without the need of
> specifying
>> something by their own.
>> In EAP draft-pala-eap-creds targets enrollment over EAP and specifically
>> addresses CMP. We also talked to Max (the author) and he is interested in
>> utilizing a lightweight CMP for this.
>> In ANIMA, we proposed BRSKI-AE to allow for enrollment in domains, which
>> are not always online or which do not feature an on-site PKI. Here, self-
>> contained objects are necessary to bind the initial authentication of an
>> enrolling device to the certification request directly, instead of binding
> it to
>> the underlying transport protocol. CMP would be applicable as one option
> for
>> providing such a self-contained object.
> Ok - I was just making sure it was real.  I don't remember the draft from
> Max.
We had some conversation with Max regarding the profiling and he was in favor as it eases the application over EAP to only the necessary exchanges.

Best regards

> Jim
>> Best regards
>> Steffen
>>> Jim
>>>> In either case your view is appreciated.
>>>> Best regards
>>>> Steffen
>>>> _______________________________________________
>>>> Spasm mailing list
>> _______________________________________________
>> Spasm mailing list