Reviewer: Yaron Sheffer Review result: Has Issues 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). -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
