Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)
Hi Barry! > -Original Message- > From: iesg On Behalf Of Barry Leiba > Sent: Friday, October 30, 2020 10:17 AM > To: Mohit Sethi M > Cc: draft-ietf-emu-eaptlsc...@ietf.org; emu@ietf.org; The IESG > ; emu-cha...@ietf.org > Subject: Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: > (with COMMENT) [snip] > On the document status issue, I'd like to hear what other working group > participants think, and also what Roman's thoughts are. Based on field experience, this document is proposing numerous ways to address parts of the problem spanning operational configuration, recommended implementation behavior and future protocol work. As the guidance does not provide unambiguous, universal guidance, I believe it does fit more appropriately in the Informational status. Roman > Barry > > On Fri, Oct 30, 2020 at 4:12 AM Mohit Sethi M > wrote: > > > > 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=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”. > > &
Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)
Thanks, Mohit, for addressing my comments... and I'm glad you also added text about the effect of quantum-safe algorithms on key and signature sizes. On the document status issue, I'd like to hear what other working group participants think, and also what Roman's thoughts are. Barry On Fri, Oct 30, 2020 at 4:12 AM Mohit Sethi M wrote: > > 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=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
Re: [Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)
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=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
[Emu] Barry Leiba's No Objection on draft-ietf-emu-eaptlscert-06: (with COMMENT)
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
