Subject: [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11

From: Dan Romascanu via Datatracker <[email-masked]>
Date: Fri, 19 Nov 2021 07:48:05 -0800

Reviewer: Dan Romascanu
Review result: Ready

This document is Ready from an OPS-DIR  perspective.

This document extends the "get-bootstrapping-data" RPC defined in RFC 8572 to
include an optional certificate signing request (CSR), enabling a bootstrapping
device to additionally obtain an identity certificate (e.g., an LDevID, from
IEEE 802.1AR) as part of the "onboarding information" response provided in the
RPC-reply. It proides the ability to provision an identity certificate that is
purpose-built for a production environment during the bootstrapping process
removing the reliance on the manufacturer CA, and enabling the bootstraped
device to join the production environment with an appropriate identity. It's a
clear and useful document, which needs to be read and understood by operators
of IOT networks using the respective technologies.

>From an operator perspective, the most relevant sections are 2 and 3. Section 
2 refers to the ietf-sztp-csr  module. It includes a Data Model Overview as
well as hints about how the augmentation and structure defined by the
"ietf-sztp-csr" module are used, including two additional tree diagrams showing
the nodes placed where they are used. I found the example usage in Section 2.2
very useful. Section 2.3 contains the YANG module. Section 3 contains the
description of the data model and the ietf-ztp-types YANG module.

I have one question related to the type of certificates that are supported.
Section 3.2 includes the following:

        The terms 'IDevID' and 'LDevID' are used herein to
        mean 'initial device identifier' and 'local device
        identifer'.  These terms are defined consistent with
        the IEEE 802.1AR specification, though there is no
        requirement that a ZTP-client's identity certificate
        conform to IEEE 802.1AR.

If my understanding is correct, the mechanism described in this document is
generic. However, all the examples and the definitions in the modules refer to
certification conform to IEEE 802.1AR. This is some kind of contradiction.
Maybe some text speaking about other types of certificates should be added. Or
maybe the scope should be defined more narrow to refer to IEEE 802.1AR. In any
case it seems to me that Std-802.1AR-2018 needs to be a Normative Reference -
one cannot understand this document without reading and understanding the IEEE
standards.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 22 Nov 2021 16:33:46 +0000

Hi Dan,

Thank you for your review.  Please see below for responses to your comments.

Kent

> On Nov 19, 2021, at 10:48 AM, Dan Romascanu via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Dan Romascanu
> Review result: Ready
> 

Your understanding is correct, the document regards device identity certificates in a generic X.509v3 sense.   Actually, a careful reading of 802.1AR shows that it, effectively, says the same, placing very few  (if any) restrictions on the contents of the X.509v3 certificate.  

That said, 802.1AR did define the terms “IDevID” and “LDevID”, which have become fairly well known in the industry.  Thusly, this document attempts to capitalize on that familiarity w/o stating that identity certificates MUST be 802.1AR-compliant.

Throughout the body of the document, the text consistently uses phraseology such as “an initial device identity certificate (e.g., an IDevID from 802.1AR)” that simultaneously doesn't bind implementations to a particular identity-certificate definition while remaining highly understandable. 

However, the text in the YANG module uses a different approach, out of a sense if brevity, by using the terms IDevID/LDevID directly (w/o any parenthetical reference to 802.1AR), along with the terminology-disclaimer you copy/pasted above.

Whilst the document appears technically accurate/unambiguous, the issue seems to warrant a remedy, as the SecDir-review made a similar comment.

Options:

1) Define formal terms for IDeviD and LDevID in Section 1.2 (Terminology) stating that 1) they are acronyms for “initial/local device identifier” and 2) they are consistent with the same terms in 802.1AR but do not imply that any implementation must adhere to 802.1AR.  This update could be coupled with the removal of all the parenthetical phraseology throughout the body of the document.

2) Modify the YANG module to 1) also use the parenthetical phraseology (greatly expanding the verbosity of the “description” statement text) and 2) remove the quoted terminology-disclaimer at the top of the YANG module.

3) Do nothing.

Which option seems best?  Does anyone have. preference?

Kent // co-author

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 23 Nov 2021 09:52:03 +0000

Hi Kent, all,

Please see inline …

From: Kent Watsen <[email-masked]>
Sent: 22 November 2021 16:34
To: Dan Romascanu <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11

Hi Dan,

Kent

On Nov 19, 2021, at 10:48 AM, Dan Romascanu via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:

Reviewer: Dan Romascanu
Review result: Ready

Options:

3) Do nothing.

I don’t think that we should do (1).  If the industry widely understands IDevID/LDevID to mean 802.1AR then redefining it in this draft to have a wider meaning could just be confusing to readers.

So I think that the draft has broadly got this right in its current approach, but I would propose also extending that to the YANG module descriptions.

Specifically, I would suggest adding a version of this paragraph to the end of the descriptions of cmc-csr and cmp-csr, which already have quite long descriptions, so the extra paragraph shouldn’t really be a problem.

I would suggest changing the description in cert-req-info to “(e.g., an IDevID from IEEE 802.1AR)”

Rob

Kent // co-author

---

From: Kent Watsen <[email-masked]>
Date: Tue, 23 Nov 2021 15:18:32 +0000

Hi Rob,

Thank you for your input.  Please see below for responses to your comments.

Kent

> I don’t think that we should do (1).  If the industry widely understands IDevID/LDevID to mean 802.1AR then redefining it in this draft to have a wider meaning could just be confusing to readers.

Agreed.

> So I think that the draft has broadly got this right in its current approach, but I would propose also extending that to the YANG module descriptions.

Agreed.

>         requirement that a ZTP-client's identity certificate

Yikes!   After sending the response to Dan, I decided on option 2 (expanding all the IDevID/LDevID usages).  In my response to Yaron yesterday I wrote:

	We updated the YANG module to greatly remove references to IDevID/LDevID.

	Specifically:
		1) s/IDevID/initial device identity certificate/g
		2) s/LDevID/local device identity certificate/g
		3) manually rewrap lines to col 69 as required
		4) removed the terminology-disclaimer block at top

	The diff is here: https://github.com/netconf-wg/sztp-csr/commit/ac35f96eec96528dddf5798d528d9874a85c604b

	Good?

This isn’t what you suggest, but it’s quite good, maybe better?   Your approach seems like it would’ve been more convenient but, given that it is what it is now, are you okay with the current edit?  [PS: I haven’t posted an updated draft yet as I’m waiting to complete the reviews with Yaron and Dan first]

> I would suggest changing the description in cert-req-info to “(e.g., an IDevID from IEEE 802.1AR)”

Done! https://github.com/netconf-wg/sztp-csr/commit/45ace9b40eedabb84e10607592d29146cb54a9c9 <https://github.com/netconf-wg/sztp-csr/commit/45ace9b40eedabb84e10607592d29146cb54a9c9>

> Rob

K.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 23 Nov 2021 15:33:36 +0000

Hi Kent,

All fine, as per inline below …

From: Kent Watsen <[email-masked]>
Sent: 23 November 2021 15:19
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Dan Romascanu <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Last-Call] [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11

Hi Rob,

Kent

Agreed.

Agreed.

              Specifically:

              Good?

Yes, what you have done is probably better – since it makes it unambiguous.

Done! https://github.com/netconf-wg/sztp-csr/commit/45ace9b40eedabb84e10607592d29146cb54a9c9

Thanks,
Rob

Rob

K.