Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08

From: Daniel Migault <[email-masked]>
Date: Wed, 1 Dec 2021 15:21:18 -0500

I believe the drafts are ready.

Yours,
Daniel

On Fri, Nov 19, 2021 at 1:03 PM Russ Housley <[email-masked]> wrote:

> This is a WG Last Call for two CMP documents.  Please review them and let
> us know whether the are ready to be sent to the IESG.  Please respond by 10
> December 2021.
>
> Title: Certificate Management Protocol (CMP) Updates
>
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates
>
> Abstract
>
>    This document contains a set of updates to the syntax and transfer of
>    Certificate Management Protocol (CMP) version 2.  This document
>    updates RFC 4210, RFC 5912, and RFC 6712.
>
>    The aspects of CMP updated in this document are using EnvelopedData
>    instead of EncryptedValue, clarifying the handling of p10cr messages,
>    improving the crypto agility, as well as adding new general message
>    types, extended key usages to identify certificates for use with CMP,
>    and '.well-known' HTTP path segments.
>
>    To properly differentiate the support of EnvelopedData instead of
>    EncryptedValue, the CMP version 3 is introduced in case a transaction
>    is supposed to use EnvelopedData.
>
>    CMP version 3 is introduced to enable signaling support of
>    EnvelopedData instead of EncryptedValue and signaling the use of an
>    explicit hash AlgorithmIdentifier in certConf messages, as far as
>    needed.
>
> Title: Lightweight Certificate Management Protocol (CMP) Profile
>
> Datatracker:
> https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile
>
> Abstract
>
>    This document aims at simple, interoperable, and automated PKI
>    management operations covering typical use cases of industrial and
>    IoT scenarios.  This is achieved by profiling the Certificate
>    Management Protocol (CMP), the related Certificate Request Message
>    Format (CRMF), and HTTP-based or CoAP-based transfer in a succinct
>    but sufficiently detailed and self-contained way.  To make secure
>    certificate management for simple scenarios and constrained devices
>    as lightweight as possible, only the most crucial types of operations
>    and options are specified as mandatory.  More special and complex use
>    cases are supported as well, by features specified as recommended or
>    optional.
>
> For the LAMPS WG Chairs,
>  Russ
>
>
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

-- 
Daniel Migault
Ericsson

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 2 Dec 2021 07:12:39 +0000

Daniel

Thank you for your review and the positive feedback.

Hendrik

Von: Spasm <[email-masked]> Im Auftrag von Daniel Migault
Gesendet: Mittwoch, 1. Dezember 2021 21:21
An: Russ Housley <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Betreff: Re: [lamps] WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08

Yours,
Daniel

On Fri, Nov 19, 2021 at 1:03 PM Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
This is a WG Last Call for two CMP documents.  Please review them and let us know whether the are ready to be sent to the IESG.  Please respond by 10 December 2021.

Datatracker: https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp-updates&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cdffa7199dcb14b1d82d908d9b50831d1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637739869083381735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=4uRarEPbBQStug7yfdJSn%2F54IzPFMVct%2BMUFmiXkvaY%3D&reserved=0>

Abstract

Datatracker: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-lightweight-cmp-profile&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cdffa7199dcb14b1d82d908d9b50831d1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637739869083381735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ESGV7gB%2FvX%2FQVRfSuKUqWz%2ByGO4YVx3Wcn3v08zEkxo%3D&reserved=0>

Abstract

For the LAMPS WG Chairs,
 Russ

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Cdffa7199dcb14b1d82d908d9b50831d1%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637739869083391690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=jgMpiG3jjUvweJXbBvw6IzQvpwVQan%2BWKY43CEzPmfw%3D&reserved=0>

--
Daniel Migault
Ericsson

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 8 Dec 2021 09:48:44 +0000

Hi,

Sorry for being late with these comment. Here are my few comments after going through the Lightweight Certificate Management Protocol document (and already getting some questions answered from Hendrik).

Best regards,
Tomas

* Just a comment: Perhaps the first reaction is that the document is very large, and does not feel lightweight. This is already stated in section 1.1 though very nicely. The document have many good clarifications of RFC4210, how it's used in reality. Imho it could as well be named "CMPv3 Profile", improving the overall interoperability in general of CMP.

On to the specific comments:

* Section 1.8:
I have some bad experiences from the usage of RFC4210 in procurement. Typically compliance with RFC4210 is a checkbox requirement, but as this group knows there is no full relevant system implementation of exactly all features and options in RFC4210 and RFC4211. This sometimes lead to confusion.
Therefore I would suggestion something like:
"An implementation is considered compliant with this profile if it implements the Mandatory PKI management operations."

* Section 3.6.1, 3.6.2, 3.6.4, 4, 4.1.1. Perhaps most specifically 4.1.1
I realize that this ask likely will not be granted, I would like to make the comment anyhow. I believe that the usage of certConf is problematic in large scale distributed systems. It adds a full transaction latency, decreases robustness of the overall system, and requires rules and potentially rather specific peristent cluster state synchronization (i.e. specific database table) for potential delayed processing (RFC4210 section 4.2.2.2). Also the threat model for using certConf is unclear to me.
I would prefer:
"Clients adhearing to this profils MUST use ImplicitConfirm and MOST NOT send certConf messages."
or perhaps weaker:
"Implementations compliant with this profile MUST support ImplicitConfirm, and MAY support certConf."

Alternative, describe the threat model for using certConf in the context of IIoT, so it's clear for implementors when to use it and when to not use it.

* Section 4.3.4, CRL update retrieval

As generically described I see some potential dangers. If CRLSource is a CDP that the client can pass arbitrarily to the server for fetching CRLs, it leads to the client making the server contact random sources on the internet, which is probably not desired. As I understand it, the CDP/Issuer fields are there to identify a CRL available on the CMP server and not ask the CRL server to go out and fetch the CRL from the CDP. This should be specified.

That perhaps should be an update to CMP Updates section, New Section 5.3.19.17:
"The DistributionPointName should be treated as an internal pointer to a CRL the server has, and not a way to ask the server to fetch CRLs from external locations".

Is there a typo in 4.3.4?

Bullet 2 says "the infoValue of the request MUST be present and contain a CRLStatus structure"
While the text below says "The infoValue field of the general request containing the id-it-crlStatusList OID looks like this...CRLSourceListValue", i.e. CRLSourceListValue vs CRLStatus.

Please reference "New Section 5.3.19.17" in CMP updates from section 4.3.4, it requires some hunting to get all the ASN.1 :-)

________________________________
From: Spasm <[email-masked]> on behalf of Brockhaus, Hendrik <[email-masked]>
Sent: Thursday, December 2, 2021 8:12 AM
To: Daniel Migault <[email-masked]>; Russ Housley <[email-masked]>
Cc: LAMPS WG <[email-masked]>
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [email-masked] with any questions.

Daniel

Hendrik

Yours,
Daniel

Datatracker: https://datatracker.ietf.org/doc/draft-ietf-lamps-cmp-updates<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp-updates&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C9efc7e68f7a54139a21308d9b5632d03%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637740260464339806%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=B8DXB2r8xkrQ9410Zx%2F9JK0mZ2ibZoRW2tZkRs7eb2o%3D&reserved=0>

Abstract

Datatracker: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-lightweight-cmp-profile&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C9efc7e68f7a54139a21308d9b5632d03%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637740260464349757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=5Le8IYLiIrTx4So5Eu%2BWN4ZI6wYkgfyVFLiipbVwdnE%3D&reserved=0>

Abstract

For the LAMPS WG Chairs,
 Russ

_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C9efc7e68f7a54139a21308d9b5632d03%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637740260464349757%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=1lF7zqqfpjVNl82Ub1pUdSSthyaoPiMi2mmVxgS31pI%3D&reserved=0>

--

Daniel Migault

Ericsson

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 8 Dec 2021 10:56:55 +0000

Tomas

Many thanks for your feedback.

> Von: Spasm <[email-masked]> Im Auftrag von Tomas Gustavsson
> Gesendet: Mittwoch, 8. Dezember 2021 10:49
>

I am open for any reasonable renaming of the document. Finally it depends on the discussion on the list.
As the mandatory to implement set of PKI management operations is very small, I still believe that the profile could be regards 'lightweight'. But you are definitely right, the overall size of the document is not lightweight any more due to many optional PKI management operations and more verbose explanations.

> "An implementation is considered compliant with this profile if it implements the Mandatory PKI management operations."

I can well understand the issue. In tenders people tend to require compliance to many standards and do not clearly specify what they are really requiring. 
My understanding is, that implementing the mandatory parts of an RFC is sufficient for compliance. If it helps for clarity, I am fine with adding this sentence.

> Alternative, describe the threat model for using certConf in the context of IIoT, so it's clear for implementors when to use it and when to not use it.

I will open a separate mail thread on implicitConfirm and certConf.

> Please reference "New Section 5.3.19.17" in CMP updates from section 4.3.4, it requires some hunting to get all the ASN.1 :-)

I will open a separate mail thread on CRL update retrieval.

Best regards,
Hendrik

---

From: Daniel Migault <[email-masked]>
Date: Wed, 8 Dec 2021 14:35:24 -0500

Hi,

I believe there is a nit in the table section 6.1:
Get certificate request template /getcacerts Section 4.3.1

Yours,
Daniel

On Wed, Dec 8, 2021 at 5:56 AM Brockhaus, Hendrik <
[email-masked]> wrote:

> > * Just a comment: Perhaps the first reaction is that the document is
> very large, and does not feel lightweight. This is already stated in
> section 1.1 though very nicely. The document have many good clarifications
> of RFC4210, how it's used in reality. Imho it could as well be named "CMPv3
> Profile", improving the overall interoperability in general of CMP.
> >
>
> As the mandatory to implement set of PKI management operations is very
> small, I still believe that the profile could be regards 'lightweight'. But
> you are definitely right, the overall size of the document is not
> lightweight any more due to many optional PKI management operations and
> more verbose explanations.
>
> > I have some bad experiences from the usage of RFC4210 in procurement.
> Typically compliance with RFC4210 is a checkbox requirement, but as this
> group knows there is no full relevant system implementation of exactly all
> features and options in RFC4210 and RFC4211. This sometimes lead to
> confusion.
> > "An implementation is considered compliant with this profile if it
> implements the Mandatory PKI management operations."
>
> I can well understand the issue. In tenders people tend to require
> compliance to many standards and do not clearly specify what they are
> really requiring.
> My understanding is, that implementing the mandatory parts of an RFC is
> sufficient for compliance. If it helps for clarity, I am fine with adding
> this sentence.
>
> >
> > I realize that this ask likely will not be granted, I would like to make
> the comment anyhow. I believe that the usage of certConf is problematic in
> large scale distributed systems. It adds a full transaction latency,
> decreases robustness of the overall system, and requires rules and
> potentially rather specific peristent cluster state synchronization (i.e.
> specific database table) for potential delayed processing (RFC4210 section
> 4.2.2.2). Also the threat model for using certConf is unclear to me.
> > I would prefer:
> > "Implementations compliant with this profile MUST support
> ImplicitConfirm, and MAY support certConf."
> >
> > Alternative, describe the threat model for using certConf in the context
> of IIoT, so it's clear for implementors when to use it and when to not use
> it.
>
> > As generically described I see some potential dangers. If CRLSource is a
> CDP that the client can pass arbitrarily to the server for fetching CRLs,
> it leads to the client making the server contact random sources on the
> internet, which is probably not desired. As I understand it, the CDP/Issuer
> fields are there to identify a CRL available on the CMP server and not ask
> the CRL server to go out and fetch the CRL from the CDP. This should be
> specified.
> >
> > "The DistributionPointName should be treated as an internal pointer to a
> CRL the server has, and not a way to ask the server to fetch CRLs from
> external locations".
> >
> > While the text below says "The infoValue field of the general request
> containing the id-it-crlStatusList OID looks like
> this...CRLSourceListValue", i.e. CRLSourceListValue vs CRLStatus.
> >
> > Please reference "New Section 5.3.19.17" in CMP updates from section
> 4.3.4, it requires some hunting to get all the ASN.1 :-)
>

-- 
Daniel Migault
Ericsson

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Thu, 9 Dec 2021 07:16:23 +0000

Daniel

Thank you for spotting this. It should be:
Old

   | Get certificate request               |   /getcacerts   | Section |

   | template                              |                 | 4.3.1   |
New

   | Get certificate request             |/getcertreqtemplate| Section |

   | template                            |                   | 4.3.3.  |

Hendrik

Von: Daniel Migault <[email-masked]>
Gesendet: Mittwoch, 8. Dezember 2021 20:35
An: Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
Cc: Tomas Gustavsson <tomas.gustavsson=[email-masked]>; LAMPS WG <[email-masked]>; Russ Housley <[email-masked]>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]>; Fries, Steffen (T RDA CST) <[email-masked]>
Betreff: Re: [lamps] WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08

Hi,

Yours,
Daniel

On Wed, Dec 8, 2021 at 5:56 AM Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:
Tomas

> Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Tomas Gustavsson

> That perhaps should be an update to CMP Updates section, New Section 5.3.19.17<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F5.3.19.17%2F&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7Ca8d1e7a6ee664c7b25ed08d9ba81e840%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637745889375027427%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=xZL3l%2FZuNmsL6UWURcAsa25FwNSaQUAv6gnzIYQ6j%2Fk%3D&reserved=0>:

Best regards,
Hendrik

--
Daniel Migault
Ericsson

---

From: Russ Housley <[email-masked]>
Date: Sat, 11 Dec 2021 16:55:32 -0500

The WG Last Call has closed.  Some issues were raised that have yet to be resolved in the document.  The issues seem fairly minor, so once those issues are sorted out, we can send these documents to the IESG.

I hope these issues can be resolved promptly.

For the LAMPS WG Chairs,
  Russ

> On Nov 19, 2021, at 1:03 PM, Russ Housley <[email-masked]> wrote:
> 
> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-lamps-lightweight-cmp-profile
> 
> Abstract
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 13 Dec 2021 10:00:15 +0000

Tomas, Russ

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[email-masked]> Im Auftrag von Brockhaus, Hendrik
> Gesendet: Mittwoch, 8. Dezember 2021 11:57
> 
> Tomas
> 
> > * Just a comment: Perhaps the first reaction is that the document is very
> large, and does not feel lightweight. This is already stated in section 1.1
> though very nicely. The document have many good clarifications of RFC4210,
> how it's used in reality. Imho it could as well be named "CMPv3 Profile",
> improving the overall interoperability in general of CMP.
> >
> 
> small, I still believe that the profile could be regards 'lightweight'. But you
> are definitely right, the overall size of the document is not lightweight any
> more due to many optional PKI management operations and more verbose
> explanations.

I propose the following change

Old text:
1.1.  How to Read This Document 

   This document has become longer than the authors would have liked it
   to be.  Yet apart from studying Section 3, which contains general
   requirements, the reader does not have to work through the whole
   document but can use the guidance in Section 1.8, Section 2.2, and
   Section 2.3 to figure out which parts of Section 4 to Section 6 are
   relevant, depending on the PKI management operations and options of
   interest.

New text:
1.1.  How to Read This Document 

   This document has become longer than the authors would have liked it
   to be.  Yet apart from studying Section 3, which contains general
   requirements, the reader does not have to work through the whole
   document but can use the guidance in Section 1.8, Section 2.2, and
   Section 2.3 to figure out which parts of Section 4 to Section 6 are
   relevant, depending on the PKI management operations, their variants
   and transfer variants of interest.

   As conformity to this document can be achieved by implementing the
   mandatory functionality, the profile can still be called lightweight, as the
   mandatory to implement set of functionality is very limited.

> sufficient for compliance. If it helps for clarity, I am fine with adding this
> sentence.

To ease the conformity statement, I propose updating Section 2.2 and 2.3 showing a Protocol Implementation Conformance Statement like section. The sections should contain two tables, one on PKI management operations and one on message transfer variants. Both tables should show the following columns compared to RFC5274 Section 4.2.

   +==========+=============================+========+========+========+
   | ID       | PKI management operations   | EE     | RA     | CA     |
   +==========+=============================+========+========+========+

Do people think, this would improve the document?
We could also move the updated Sections 2.2 and 2.3 to a new Section 7 or to an Appendix.

Hendrik

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Dec 2021 10:07:57 -0500

I think that a table like RFC5274 Section 4.2 would be very helpful.

Russ

> On Dec 13, 2021, at 5:00 AM, Brockhaus, Hendrik <[email-masked]> wrote:
> 
> Tomas, Russ
>

---

From: Tomas Gustavsson <[email-masked]>
Date: Mon, 13 Dec 2021 15:50:57 +0000

Agreed. I like your suggestions Hendrik.
________________________________
From: Russ Housley <[email-masked]>
Sent: Monday, December 13, 2021 4:07 PM
To: Brockhaus, Hendrik <[email-masked]>
Cc: Tomas Gustavsson <[email-masked]>; Daniel Migault <[email-masked]>; LAMPS WG <[email-masked]>; [email-masked] <[email-masked]>; Fries, Steffen <[email-masked]>
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08

Russ

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C5ffd3d2c26244e362fe008d9be4a6235%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637750048976458763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QOZev%2FsZoa3%2BCeOtmEaw5%2BDNXqGXiTp6TD7JFCXfLl4%3D&amp;reserved=0

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 13 Dec 2021 18:36:19 +0000

Russ, Tomas

Thank you fort he clear feedback.
I will add these tables as new Section 7 and extend the text in Section 1.1 a little with the more general parts of Sections 2.2 and 2.3.

Hendrik

Von: Tomas Gustavsson <[email-masked]>
Gesendet: Montag, 13. Dezember 2021 16:51
An: Russ Housley <[email-masked]>; Brockhaus, Hendrik (T RDA CST SEA-DE) <[email-masked]>
Cc: Daniel Migault <[email-masked]>; LAMPS WG <[email-masked]>; von Oheimb, David (T RDA CST SEA-DE) <[email-masked]>; Fries, Steffen (T RDA CST) <[email-masked]>
Betreff: Re: [lamps] WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08

Agreed. I like your suggestions Hendrik.
________________________________
From: Russ Housley <[email-masked]<mailto:[email-masked]>>
Sent: Monday, December 13, 2021 4:07 PM
To: Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>>
Cc: Tomas Gustavsson <[email-masked]<mailto:[email-masked]>>; Daniel Migault <[email-masked]<mailto:[email-masked]>>; LAMPS WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Fries, Steffen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [lamps] WG Last Call for draft-ietf-lamps-cmp-updates-14 and draft-ietf-lamps-lightweight-cmp-profile-08

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [email-masked]<mailto:[email-masked]> with any questions.

Russ

> On Dec 13, 2021, at 5:00 AM, Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:
>
> Tomas, Russ
>
>> Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Brockhaus, Hendrik
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Ctomas.gustavsson%40primekey.com%7C5ffd3d2c26244e362fe008d9be4a6235%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637750048976458763%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=QOZev%2FsZoa3%2BCeOtmEaw5%2BDNXqGXiTp6TD7JFCXfLl4%3D&amp;reserved=0<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C1892cbbabbff463cea1308d9be5061d4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637750074723311189%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SsIx%2BCUbGWcj%2B4X698A%2BYDBolCEDzpi4%2BQDLhw26WWU%3D&reserved=0>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 17 Dec 2021 16:06:09 +0000

Russ

I just submitted updates of both drafts on behalf of the authors hoping all comments were sufficiently addressed.
If I missed something, please let me know and as always, any comments are welcome.

Hendrik

> Von: Spasm <[email-masked]> Im Auftrag von Russ Housley
> Gesendet: Samstag, 11. Dezember 2021 22:56
> 
> The WG Last Call has closed.  Some issues were raised that have yet to be
> resolved in the document.  The issues seem fairly minor, so once those
> issues are sorted out, we can send these documents to the IESG.
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-cmp-
> updates&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C09b
> 35b22b0fe4f3fcfa508d9bcf0fe48%7C38ae3bcd95794fd4addab42e1495d55a%7
> C1%7C0%7C637748565529804376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> &amp;sdata=JXMEvzhGDfHI5Jtk2KQS4LvEPYIvk3POFFAgXF7ZfS8%3D&amp;res
> erved=0
> >
> > Abstract
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatr
> acker.ietf.org%2Fdoc%2Fdraft-ietf-lamps-lightweight-cmp-
> profile&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C09b3
> 5b22b0fe4f3fcfa508d9bcf0fe48%7C38ae3bcd95794fd4addab42e1495d55a%7
> C1%7C0%7C637748565529804376%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000
> &amp;sdata=zcFD4BTbY%2BtBQ4miB2TqjcQxZYjZsWF%2FvrA879HGRQU%3D
> &amp;reserved=0
> >
> > Abstract
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.i
> etf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=04%7C01%7Chendrik.br
> ockhaus%40siemens.com%7C09b35b22b0fe4f3fcfa508d9bcf0fe48%7C38ae3bc
> d95794fd4addab42e1495d55a%7C1%7C0%7C637748565529804376%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1h
> aWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=kDxW0XH1qrgN9u0xUTNRW1Ik
> q5joGmaVzkK44htvPog%3D&amp;reserved=0