Last Call Review of draft-ietf-netconf-sztp-csr-11
review-ietf-netconf-sztp-csr-11-secdir-lc-sheffer-2021-11-17-00

This draft defines a mechanism for a device, when it first starts, to generate
a CSR to get itself provisioned with one or more certificates it needs to
identify itself during its normal operation.

* I was confused that the document starts out describing a generic cert request
mechanism. Then deep into the YANG modules, it turns out that there is guidance
(only?) for very specific types of certs, namely LDevID and IDevID. And the
choice is non-orthogonal: it is unclear what is the guidance for other certs
when using CMC and CMP, and conversely, whether these two certs can be
generated with a PKCS#10 CSR.

* I suggest adding a Security Considerations section about the need for strong
randomness, which is often unavailable to small embedded devices at the early
stages of provisioning. I wish we were more successful with: 
https://datatracker.ietf.org/doc/html/draft-sheffer-dhc-initial-random-00

* Negotiation (?) of the CSR format and supported algorithms is unclear in Sec.
2.2: is it the client that provides the values it supports and the server picks
one? Alternatively, is the list conveyed by the server in the error-info and so
the client knows exactly what is supported? IOW, why include these values at
all in error-info?

* It is not clear from Sec. 2.2 how exactly the client is supposed to associate
one of possibly multiple received certificates to the CSR it just sent out.
Surely it is not expected to grep for the string "Newly-Generated"?

* 2.3: the description of "error-info" still does not specify if the server
should list all CSR format and algorithms it supports.

* Is there really need to support 3 different CSR formats?

* Where does the client indicate which cert is wants to receive based on this
CSR, e.g. "this CSR is for a LDevID"? Is this information embedded in the CSR
itself?

* Is RFC 2986 (published Nov. 2000) the best reference for an
AlgorithmIdentifier? Is there no IANA registry we could reference instead?

* When talking about algorithm matching, I suggest changing "It is an error
if..." into normative text, "The recipient MUST reject...".

* "Details for how to generate a new private key and associate a new identity
certificate are outside the scope of this document." - This is rather
disappointing, since we just RECOMMENDED to regenerate certs periodically (and
given that IOT devices often lack HSMs).