| Hi Yaron, Thank you for your valuable comments. My co-authors and I have the following responses to your comments.
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?
OLD: It is RECOMMENDED that a new private key is generated for each CSR described in this document. NEW: It is RECOMMENDED that a new private key is generated for each CSR described in this document. This private key MUST be generated using a quality random source. The use of inadequate pseudo-random number generators (PRNGs) to generate private keys can result in little or no security. An attacker may find it much easier to reproduce the PRNG environment that produced the private key, searching the resulting small set of possibilities, rather than brute force searching the whole private key space. The generation of quality random numbers is difficult. BCP 106 [RFC4086] offers important guidance in this area. and we added an Informational reference to RFC 4086. Good now?
Section 2.1 states the sequence of exchanges, but we went ahead and added more context to the examples for additional clarity. The diff is here: https://github.com/netconf-wg/sztp-csr/commit/7ed4f5b1daee539dc9071061e4d427e843467d02 Better?
There doesn’t have to be any logic on the client to detect the signed certificate or, for that matter, to ensure that the server sent one at all. The point of the bootstrap process is to *configure* the SZTP-client, and the client's only post-update logic is to “run as configured”, whatever that might be. That said, it wouldn’t be hard for a client to, e.g., search a “keystore" mechanism for a key having the key used in the CSR and then search certificates associated with that key for that cert having the matching attributes (e.g., the “Subject” attribute) as in the CSR. Makes sense? [No update to the draft was made to address this comment]
Section 2.1 indicates that the client’s message lists all of the key-algorithms and csr-formats it supports and the server’s message merely selects the specific algorithm/format it wishes the client use. This comment is nearly identical to one of your earlier comments, for which we added more context around the examples. Good enough?
Yes and, FWIW, the PKI world has even more formats; we actually restricted them to just those that are most widely implemented.
The CSR is always for an LDevID. It can never be for an IDevID, which can (effectively) only be generated/installed by the vendor during the device’s manufacturing process. Makes sense? [No update to the draft was made to address this comment]
[No update to the draft was made to address this comment]
OLD: It is an error if the 'AlgorithmIdentifier' field contained inside the 'SubjectPublicKeyInfo' field does not match the algorithm identified by the 'selected-algorithm' node."; NEW: If the 'AlgorithmIdentifier' field contained inside the certificate 'SubjectPublicKeyInfo' field does not match the algorithm identified by the 'selected-algorithm' node, then the client MUST reject the certificate and raise an error."; Good?
Understood, but key-generation is indeed outside the scope of this document. [No update to the draft was made to address this comment] Thanks again, Kent (and Sean and Russ) |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
