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
