Re: [Last-Call] [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11

["Rob Wilton \(rwilton\)" <rwilton=40cisco.com@xxxxxxxxxxxxxx>]

Hi Kent, all,

 

Please see inline …

 

From: Kent Watsen <kent@xxxxxxxxxx>
Sent: 22 November 2021 16:34
To: Dan Romascanu <dromasca@xxxxxxxxx>
Cc: ops-dir@xxxxxxxx; last-call@xxxxxxxx; draft-ietf-netconf-sztp-csr.all@xxxxxxxx; netconf@xxxxxxxx
Subject: Re: [netconf] Opsdir last call review of draft-ietf-netconf-sztp-csr-11

 

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 <noreply@xxxxxxxx> wrote:

 

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.

 

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?

 

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.

 

        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.

 

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

 

Rob

 

Kent // co-author

 

 

 

 

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call