Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods
RFC 9191

Received changes through RFC Editor sync (created alias RFC 9191, changed title to 'Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods', changed abstract to 'The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods.  EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication.  Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem.  This document looks at this problem in detail and describes the potential solutions available.', changed pages to 12, changed standardization level to Informational, changed state to RFC, added RFC published event at 2022-02-15, changed IESG state to RFC Published)

[Ballot comment]
Ending this round of IESG evaluation reviews with this document. Good choice as it is easy to read, addresses a real problem, and provides a lot of common sense/sensible suggestions.

Like noted by Barry and others, I think that this document could aim for a 'higher grade' status (BCP for example); OTOH, some sections such as 4.2.3 propose protocol extensions that won't fit in a BCP or PS.

Regards

-éric

[Ballot comment]
Ending this round of IESG evaluation review with this document. Good choice as it is easy to read, addresses a real problem, and provides a lot of common sense/sensible suggestions.

Like noted by Barry and others, I think that this document could aim for a 'higher grade' status (BCP for example); OTOH, some sections such as 4.2.3 proposes protocol extensions that won't fit in a BCP or PS).

Regards

-éric

[Ballot comment]
Thanks for this.  I second Robert's comments on this being easy to read and enlightening.

I note that the only use of BCP 14 language is a single SHOULD NOT in Section 4.1.3.  You might be able to simplify this away with some light editing.

[Ballot comment]
Thank you for responding to the secdir review and thanks to Stefan
Santesson for the review -- the changes staged in github are a
significant improvement!

Though I am balloting Yes, please see my remarks about
draft-thomson-tls-sic in the comments on Section 4.2.5 -- it is expired
and was not adopted by the TLS WG and we should not imply that it is a
current work item there.

I also made a pull request at
https://github.com/emu-wg/eaptls-longcert/pull/4 with a few editorial
fixes/suggestions.

Section 3

  o  Multiple user groups in the certificate.

What are "user groups" in a certificate?

  A certificate chain (called a certification path in [RFC5280]) can
  commonly have 2 - 6 intermediate certificates between the end-entity
  certificate and the trust anchor.

The '2' here is surprising to me; my understanding was that having just
1 intermediate was quite common, especially on the web.

  Many access point implementations drop EAP sessions that do not
  complete within 50 round-trips.  This means that if the chain is

Earlier we said "40 - 50"; we should probably be consistent about it.

Section 4.1

  1.3 [RFC8446] requires implementations to support ECC.  New cipher
  suites that use ECC are also specified for TLS 1.2 [RFC5289].  Using

nit: RFC 8422 might be a better reference than 5289, here.

Section 4.1.3

  The EAP peer certificate chain does not have to mirror the
  organizational hierarchy.  For successful EAP-TLS authentication,
  certificate chains SHOULD NOT contain more than 2-4 intermediate
  certificates.

This seems equivalent to the shorter "SHOULD NOT contain more than 4
intermediate certificates".

Section 4.2

  by updating the underlying TLS or EAP-TLS implementation.  Note that
  in many cases the new feature may already be implemented in the
  underlying library and simply needs to be taken into use.

Hmm, "many" might be a stretch, given that the majority of the
mechanisms we refer to are still at the internet-draft stage.

Section 4.2.2

  possible.  An option in such a scenario would be to cache validated
  certificate chains even if the EAP-TLS exchange fails, but this is
  currently not allowed according to [RFC7924].

This is arguably not a strict requirement in 7924; the text in question
looks to be:

% Clients MUST ensure that they only cache information from legitimate
% sources.  For example, when the client populates the cache from a TLS
% exchange, then it must only cache information after the successful
% completion of a TLS exchange to ensure that an attacker does not
% inject incorrect information into the cache.  Failure to do so allows
% for man-in-the-middle attacks.

The normative MUST is for "legitimate sources", and "only after
successful TLS exchange" uses the lowercase MUST.  Of course, 7924
predates 8174, so it's not fully clear-cut, but there may be some ground
to stand on for caching validated certificate chains prior to a
completed TLS handshake (provided that other validation is performed
properly).

Section 4.2.4

  "known certificates".  Thus, cTLS can provide another mechanism for
  EAP-TLS deployments to reduce the size of messages and avoid
  excessive fragmentation.

cTLS is at a fairly early stage; it might be better to say "could
provide" rather than "can provide".

Section 4.2.5

  handshake increases the size of the handshake unnecessarily.  The TLS
  working group is working on an extension for TLS 1.3
  [I-D.thomson-tls-sic] that allows a TLS client that has access to the

It is not accurate or appropriate to say that "the TLS working group is
working on" an individual I-D that is not adopted by the WG.
Suppressing intermediate certificates might be more appopriate in the
"new certificate types and compression algorithms" section, that seems
to be the home for most of the still-speculative stuff.

Section 4.2.6

  certificate chains.  Deployments can consider their use as long as an
  appropriate out-of-band mechanism for binding public keys with
  identifiers is in place.

It is also important to consider revocation and key rotation when
considering the use of raw public keys.

Section 6

We probably want a general disclaimer that the security considerations
of the referenced documents apply, in addition to whichever pieces we
cherry-pick for specific mention.  (In light of my previous comment
about draft-thomson-tls-sic, we may want to not use that as one of the
things to cherry-pick for special mention.)

We might also mention that various ways to avoid sending certificates
over the wire do not obviate the endpoints' responsibility to check
revocation information.

Similarly, efforts to trim certificate size should not remove extensions
or other attributes that are necessary for secure operation (though that
is perhaps a bit banal to actually say).

Section 7.2

I think RFC 8446 needs to be a normative reference.

[Ballot comment]
Thank you for this document.  I found it informative, easy to read, and enlightening on a problem that I wasn't aware of.

I agree with Barry comment that it would be useful to talk about whether this should be a BCP or Informational.

Regards,
Rob

[Ballot 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!

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-emu-eaptlscert-05, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-10-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-emu-eaptlscert@ietf.org, joe@salowey.net, rdd@cert.org, Joseph Salowey , emu-chairs@ietf.org, emu@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods) to Informational RFC


The IESG has received a request from the EAP Method Update WG (emu) to
consider the following document: - 'Handling Large Certificates and Long
Certificate Chains in TLS-based
  EAP Methods'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-10-28. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  EAP-TLS and other TLS-based EAP methods are widely deployed and used
  for network access authentication.  Large certificates and long
  certificate chains combined with authenticators that drop an EAP
  session after only 40 - 50 round-trips is a major deployment problem.
  This document looks at the this problem in detail and describes the
  potential solutions available.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is indicated as information in the document header.  This is appropriate because the document does not define a new protocol but describes considerations for handling large certificates in an existing protocol. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  EAP-TLS and other TLS-based EAP methods are widely deployed and used
  for network access authentication.  Large certificates and long
  certificate chains combined with authenticators that drop an EAP
  session after only 40 - 50 round-trips is a major deployment problem.
  This document looks at the this problem in detail and describes the
  potential solutions available.

Working Group Summary:

There was good support in the working group for this document.  There we
several substantive reviews of the document.

Document Quality:

This document has be reviewed by members of the EAP and the TLS community.  Some of the mechanisms in the document are being implemented.

Personnel:

Joseph Salowey is the document shepherd and Roman Danyliw is the responsible AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has read through the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

NA

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good consensus among the segment of the working group interested in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The shepherd did not find any nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is indicated as information in the document header.  This is appropriate because the document does not define a new protocol but describes considerations for handling large certificates in an existing protocol. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  EAP-TLS and other TLS-based EAP methods are widely deployed and used
  for network access authentication.  Large certificates and long
  certificate chains combined with authenticators that drop an EAP
  session after only 40 - 50 round-trips is a major deployment problem.
  This document looks at the this problem in detail and describes the
  potential solutions available.

Working Group Summary:

There was good support in the working group for this document.  There we
several substantive reviews of the document.

Document Quality:

This document has be reviewed by members of the EAP and the TLS community.  Some of the mechanisms in the document are being implemented.

Personnel:

Joseph Salowey is the document shepherd and Roman Danyliw is the responsible AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has read through the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

NA

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good consensus among the segment of the working group interested in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The shepherd did not find any nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is indicated as information in the document header.  This is appropriate because the document does not define a new protocol but describes considerations for handling large certificates in an existing protocol. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  EAP-TLS and other TLS-based EAP methods are widely deployed and used
  for network access authentication.  Large certificates and long
  certificate chains combined with authenticators that drop an EAP
  session after only 40 - 50 round-trips is a major deployment problem.
  This document looks at the this problem in detail and describes the
  potential solutions available.

Working Group Summary:

There was good support in the working group for this document.  There we
several substantive reviews of the document.

Document Quality:

This document has be reviewed by members of the EAP and the TLS community.  Some of the mechanisms in the document are being implemented.

Personnel:

Joseph Salowey is the document shepherd and Ben Kaduk is the responsible AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has read through the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

NA

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good consensus among the segment of the working group interested in this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The shepherd did not find any nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is indicated as information in the document header.  This is appropriate because the document does not define a new protocol but describes considerations for handling large certificates in an existing protocol. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  EAP-TLS and other TLS-based EAP methods are widely deployed and used
  for network access authentication.  Large certificates and long
  certificate chains combined with authenticators that drop an EAP
  session after only 40 - 50 round-trips is a major deployment problem.
  This document looks at the this problem in detail and describes the
  potential solutions available.

Working Group Summary:

There was good support in the working group for this document.  There we
several substantive reviews of the document.

Document Quality:

This document has be reviewed by members of the EAP and the TLS community. 

Personnel:

Joseph Salowey is the document shepherd and Ben Kaduk is the responsible AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has read through the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

NA

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

There is good consensus in the working group around this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The shepherd did not find any nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

(13) Have all references within this document been identified as either normative or informative?

yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

N/A

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

N/A

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

N/A

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

This document is indicated as information in the document header.  This is appropriate because the document does not define a new protocol but describes considerations for handling large certificates in an existing protocol. 

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  EAP-TLS and other TLS-based EAP methods are widely deployed and used
  for network access authentication.  Large certificates and long
  certificate chains combined with authenticators that drop an EAP
  session after only 40 - 50 round-trips is a major deployment problem.
  This document looks at the this problem in detail and describes the
  potential solutions available.

Working Group Summary:

There was strong support in the working group for this document. 

Document Quality:

This document has be reviewed by members of the EAP and the TLS community. 

Personnel:

Joseph Salowey is the document shepherd and Ben Kaduk is the responsible AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd has read through the document and believes it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

NA

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosure has been filed

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

N/A

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or informative?

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?