Hi Barry, Thank you for the careful review. I have updated the draft in github (https://github.com/emu-wg/eaptls-longcert). Here is the diff for your convenience: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt&url2=https://emu-wg.github.io/eaptls-longcert/draft-ietf-emu-eaptlscert.txt. I will wait for all the comments to come in before submitting a new version.
Regarding your comment of informational vs. applicability statement: I am not opposed to the idea. I am happy to follow whatever the IESG recommends. --Mohit On 10/28/20 9:21 PM, Barry Leiba via Datatracker wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-emu-eaptlscert-06: 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-emu-eaptlscert/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this; it will be useful to have this issue fixed. > > There’s something I’d like to discuss, but without making it a blocking > DISCUSS: > While I understand the reason for putting this forward as Informational, it > does strike me more as a Standards Track Applicability Statement. BCP 9 says > (in RFC 2026 Section 3.2): > > An Applicability Statement specifies how, and under what > circumstances, one or more TSs may be applied to support a particular > Internet capability. > > Reading the rest of Section 3.2 as well, I think that it fits exactly what > you’re doing with this document: the document is saying that there’s an > interoperability problem with large certs and long chains, and here are things > to do in order to make that work. Let’s please have a brief discussion about > whether this should instead be published at Proposed Standard as an AS. > > ————— > > Below are some nits that I hope you’ll consider, but there’s no need to > respond > in detail here; please do as you think best. > > — Section 1 — > > vendor specific EAP methods. > > Need a hyphen in “vendor-specific”. > > EAP-TLS > deployments typically authenticates both the EAP peer and the EAP > > Make it “authenticate”. > > Section 3.1 of [RFC3748] states that EAP implementations can assume a > MTU of at least 1020 octets from lower layers. > > Unless you have a way of pronouncing “MTU” that I don’t, make it “an MTU”. > > Such fragmentation can not only negatively > affect the latency, but also results in other challenges. > > The “can” is misplaced; make it “not only can affect”. > > — Section 2 — > > The document additionally uses the terms trust anchor and > certification path defined in [RFC5280]. > > I would put “trust anchor” and “certification path” in quotes here. > > — Section 3 — > > Certificate sizes can however be large > > Commas are needed both before and after “however”. Also, the list talks about > a singular “certificate”, so the lead-in should match that (and you don’t need > to say that a *size* can be large): “A certificate can, however, be large for > a > number of reasons:” > > The list is also not parallel (the third item, in particular, is not like the > others). I would make the whole list be complete sentences, like this, > referring to “a certificate” in the lead-in: > > NEW > o It can have a long Subject Alternative Name field. > > o It can have long Public Key and Signature fields. > > o It can contain multiple object identifiers (OID) that indicate the > permitted uses of the certificate as noted in Section 5.3 of > [RFC5216]. Most implementations verify the presence of these OIDs > for successful authentication. > > o It can contain multiple user groups. > END > > — Section 4.1 — > > Throughout this paragraph you refer to “size of public keys” and “size of > digital signatures”. It’s a really nitty nit, but I would make these all > singular, because we’re really talking about the size of an individual public > key or digital signature, not the size of a collection of them. > > authentication which can alleviate the problem of authenticators > > There needs to be a comma before “which”. > > ECC based cipher suites with existing code can significantly > > Hyphenate “ECC-based”. > > — Section 4.1.1 — > > OIDs are used lavishly in X.509 certificates > > I like it: “lavishly” is not a word we often see in RFCs. :-) > > DNs > used in the issuer and subject fields as well as numerous > extensions. > > This is not a complete sentence; please fix that (I think you’re just missing > “are” after “DNs”). > > CN=Coolest IoT Gadget Ever > > Oh! I want that! > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
