Thanks, Panos; it all looks good, and thanks for considering my comments. Barry
On Tue, Dec 24, 2019 at 10:50 AM Panos Kampanakis (pkampana) <pkamp...@cisco.com> wrote: > > Hi Barry, > > This commit > https://github.com/SanKumar2015/EST-coaps/commit/01f7014e2348d09c0a1ff768eea7d53f4c5471f2 > tries to address your feedback. The full discussion is in > https://github.com/SanKumar2015/EST-coaps/issues/153 > > Let us know if it does not make sense. > > Rgs, > Panos > > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Panos Kampanakis (pkampana) > Sent: Saturday, December 21, 2019 10:49 PM > To: Barry Leiba <barryle...@computer.org>; The IESG <i...@ietf.org> > Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; > ace-cha...@ietf.org; ace@ietf.org > Subject: Re: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: > (with COMMENT) > > Hi Barry, > > Thank you for the thorough review. We are tracking your feedback and our > responses in a git issue https://github.com/SanKumar2015/EST-coaps/issues/153 > We mostly confirm all your minor text changes and nit fixes. The TBD one we > will not fix as we are waiting on IANA. > > Let us know if something does not make sense. > > Rgs, > Panos > > > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Barry Leiba via Datatracker > Sent: Monday, December 16, 2019 9:59 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-ace-coap-...@ietf.org; i...@augustcellars.com; > ace-cha...@ietf.org; ace@ietf.org > Subject: [Ace] Barry Leiba's No Objection on draft-ietf-ace-coap-est-17: > (with COMMENT) > > Barry Leiba has entered the following ballot position for > draft-ietf-ace-coap-est-17: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ace-coap-est/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this — a useful document. I have a bunch of comments, but they’re > all editorial. Please consider them, but there’s not a need to give a > detailed reply. > > -- Section 4 -- > > In that case, the > server MAY want to authenticate a client certificate against its > trust store although the certificate is expired (Section 10). > > Total nit: Why "want to"? Why not "server MAY authenticate"? > > As described in Section 2.1 of [RFC5272] proof-of-identity refers to > a value that can be used to prove that the private key corresponding > to the certified public key is in the possession of and can be used > by an end-entity or client. > > I find the passive voice to be quite awkward here, and suggest making it > active: > > NEW > As described in Section 2.1 of [RFC5272], proof-of-identity refers > to a value that can be used to prove that an end-entity or client is > in possession of and can use the private key corresponding to the > certified public key. > END > > the event of handshake message fragmentation, the Hash of the > handshake messages used in the MAC calculation of the Finished > message must be computed as if each handshake message had been sent > as a single fragment (Section 4.2.6 of [RFC6347]). > > I know this wording is directly from 6347, but I think it's unclear and would > like to suggest an alternative. The "as a single fragment" part is odd, > because I think what it's really saying is that it's computed as if it had > not been fragmented. My suggestion is to change it thus (and similarly for > the next paragraph after): > > NEW > the event of handshake message fragmentation, the Hash of the > handshake messages used in the MAC calculation of the Finished > message must be computed on each reassembled message, as if > each handshake message had not been fragmented (Section 4.2.6 > of [RFC6347]). > END > > If that's not correct, please take that as further evidence that it's > unclear, and adjust accordingly. > > To alleviate this > situation, an EST-coaps DTLS connection MAY remain open for > sequential EST transactions which was not the case with [RFC7030]. > For example, an EST csrattrs request that is followed by a > simpleenroll request can use the same authenticated DTLS connection. > > Two total nits: > a. Comma before "which", please. > b. The "for example" needs some rewording to make it work: > NEW > For example, if an EST csrattrs request is followed by a > simpleenroll request, both can use the same authenticated > DTLS connection. > END > > -- Section 5.1 -- > > EST-coaps is targeted for low-resource networks with small packets. > Two types of installations are possible (1) rigid ones where the > address and the supported functions of the EST server(s) are known, > and (2) flexible one where the EST server and it supported functions > need to be discovered. > > This needs a colon (:) after "possible", a comma after "rigid ones", "a" > before "flexible one", another comma after "flexible one", and make it "its > supported". > > -- Section 5.5 -- > > Similarly, 2.04 > > is used in successfull response to EST-coaps POST requests (/sen, > /sren, /skg, /skc). > > There's odd spacing here; please fix it. And "successful" is misspelled. > > -- Section 5.7 -- > > If the server is very slow (i.e., minutes) in providing the response > (i.e., when a manual intervention is needed), > > I think you mean "e.g." for both of those, evidence for my general aversion > to using Latin abbreviations that many people don't fully understand. It > also feels odd to have the two examples separated in this way. I suggest > this: > > NEW > If the server is very slow in providing the response (for example, > manual intervention is required and it could take minutes for it > to respond), > END > > it SHOULD respond with > an ACK containing response code 5.03 (Service unavailable) and a Max- > Age Option to indicate the time the client SHOULD wait to request the > content later. > > Perhaps, "to indicate the time the client SHOULD wait before sending another > request to obtain the content." ? > > After a delay of Max-Age, the client SHOULD resend > the identical CSR to the server. As long as the server responds with > response code 5.03 (Service Unavailable) with a Max-Age Option, the > client SHOULD keep resending the enrollment request until the server > responds with the certificate or the client abandons the request for > other reasons. > > That last sentence reads very strangely to me. It SHOULD keep resending the > request until it decides to stop? What does that actually mean? > > Maybe what you're really trying to say is something like this?: > > NEW > As long as the server continues responding with > response code 5.03 (Service Unavailable) with a Max-Age Option, the > client will continue to delay for Max-Age and then resend the > enrollment request until the server responds with the certificate or > the client abandons the request for policy or other reasons. > END > > -- Section 5.8 -- > > In scenarios where it is desirable that the server generates the > private key, server-side key generation is available. > > This seems like a content-free sentence. Maybe this?: > > NEW > Private keys can be generated on the server. Scenarios where > that makes sense include those where it is considered more > secure... > END > > Of course, that does not eliminate the > need for proper random numbers in various protocols like (D)TLS > (Section 10.1). > > May I suggest this?: > > NEW > As always, it is necessary to use proper random numbers in > various protocols such as (D)TLS (Section 10.1). > END > > server or proxy to generate the private key and the certificate which > are transferred back to the client > > Needs a comma before "which". > > or the asymmetric keypair establishment method is out of scope of the > specification. > > "of this specification". > > [I-D.ietf-core-multipart-ct] containing a CBOR array with four items > > (Section 5.3) > > . The two representations > > More odd spacing. > > Dependent on the request, the > private key can be in unprotected PKCS#8 [RFC5958] format > > "Depending upon the request" > > In > the case where the asymmetric encryption key is suitable for > transport key operations the generated private key is encrypted with > a symmetric key which is encrypted by the client-defined (in the CSR) > asymmetric public key and is carried in an encryptedKey attribute in > a KeyTransRecipientInfo structure. > > Long sentence that needs punctuation: comma after "operations", comma before > "which", comma before "and". Also, I would move "(in the CSR)" a few words > later, after "public key". > > -- Section 7 -- > > It is recommended, based on experiments, > > to follow the default CoAP configuration parameters ([RFC7252]). > > Odd spacing, again. But "it is recommended to follow" is also odd English. > I suggest making this active, rather than passive, thus: > > NEW > Implementations should follow the default CoAP configuration > parameters ([RFC7252]). > END > > I don't think the "based on experiments" bit adds anything, but if you want > to keep it you can prepend "Experiments have shown that" to my suggestion. > > -- Section 9.1 -- > Don't you want to remove the "TBD" on "TBD287" here? Wasn't the "TBD" just a > flag to remind people that it hadn't been formally allocated yet? > > — Section 10.1 — > > It is important to note that sources contributing to the randomness > pool used to generate random numbers on laptops or desktop PCs are > not available on many constrained devices, such as mouse movement, > timing of keystrokes, or air turbulence on the movement of hard drive > heads, as pointed out in [PsQs]. > > The sentence order is wrong here. For example, mouse movement is not a > constrained device. The correct order is more like this: > > NEW > It is important to note that, as pointed out in [PsQs], sources > contributing to the randomness pool used to generate random > numbers on laptops or desktop PCs, such as mouse movement, > timing of keystrokes, or air turbulence on the movement of hard > drive heads, are not available on many constrained devices. > END > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
