Skip to main content

Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods
draft-ietf-emu-eaptlscert-08

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Joseph Salowey <joe@salowey.net>, The IESG <iesg@ietf.org>, draft-ietf-emu-eaptlscert@ietf.org, emu-chairs@ietf.org, emu@ietf.org, joe@salowey.net, rdd@cert.org, rfc-editor@rfc-editor.org
Subject: Document Action: 'Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods' to Informational RFC (draft-ietf-emu-eaptlscert-08.txt)

The IESG has approved the following document:
- 'Handling Large Certificates and Long Certificate Chains in TLS-based
   EAP Methods'
  (draft-ietf-emu-eaptlscert-08.txt) as Informational RFC

This document is the product of the EAP Method Update Working Group.

The IESG contact persons are Benjamin Kaduk and Roman Danyliw.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/


Ballot Text

Technical Summary

   The Extensible Authentication Protocol (EAP), defined in RFC3748,
   provides a standard mechanism for support of multiple authentication
   methods.  EAP-Transport Layer Security (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
Roman Danyliw is the responsible AD

RFC Editor Note