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

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 8 Dec 2021 16:48:54 +0000

Tomas

Regarding implicitConfirm and certConf

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

> Gesendet: Mittwoch, 8. Dezember 2021 10:49

> * 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.

I understand that the confirmation roundtrip is an extra burden for the EE as well as for the RA/CA. I also understand the complexity on a large scale distributed CA server system.

Currently this extra roundtrip is required not only in the MTI Appendix D.4 of RFC4210. It was also adopted by LTE/3GPP and UNISG Subset-137. Also BRSKI specifies such extra roundtrip confirming the successful bootstrapping in RFC8995 Section 5.9.4 as EST does not offer such enrollment status message.

In a managed and highly automated IoT environment consisting of many unattended devices successful certificate management is an important functionality. Especially unattended or constrained devices have only limited or even no capabilities regarding trouble shooting and do not offer any GUI. In case such EE was not successfully enrolled, this EE cannot solve the issues itself. On the other hand a central infrastructure, that is aware of the failed enrollment, has appropriate capabilities handling such issue. Therefore, I believe that making use of the certConf message is a valuable feature and worth the extra roundtrip.
I hope this explains our background of requiring this feature as mandatory to implement.

Anyhow, I also see that this reasoning is not valid for all environments. There may also be environments preferring to reduce the enrollment to one roundtrip only.  Therefore, I like the option that an EE may request implicitConfirm. But I would prefer keeping the certConf as part of the MIT feature set.

What do others think?

Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 15 Dec 2021 17:26:12 +0000

Thanks to the good discussion with Tomas today, we managed to agree on a proposal how to handle implicitConfirm and certConf.

- Keeping the certConf roundtrip mandatory to implement and optional to use. The usage of the second certConf roundtrip should be a policy decision of the PKI management entity. The EE should offer reducing the enrollment to one roundtrip and it should be the policy decision of the PKI management entity requiring the extra certConf roundtrip.
- The profile will leave it up to the policy of the PKI management entity how to handle a negative certConf message, e.g., if it must revoke the rejected certificate, just notifies a monitoring system, or only logs the event.
- We will add a paragraph discussing the pros and cons of the extra certConf roundtrip, e.g., the advantages of one vs. two roundtrips or that a central management components may need to know if the enrollment was successful.

Any thoughts?

Hendrik

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