PEM file format for ECH
draft-farrell-tls-pemesni-13

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-farrell-tls-pemesni and RFC 9934, changed IESG state to RFC Published)

[Ballot comment]
I support Med Boucadair’s DISCUSS feedback.
** Abstract.  Editorial.
  Encrypted ClientHello (ECH) key pairs need to be configured into TLS
  servers, which can be built using different TLS libraries, so there
  is a benefit and little cost in documenting a file format to use for
  these key pairs, similar to how RFC 7468 defines other PEM file
  formats.
Consider if defining this file format needs to be rationalized.  Maybe just a straight declaration of what it is:

NEW
Encrypted ClientHello (ECH) key pairs need to be configured into TLS 1.3 servers when the ECH feature is used.  This document specifies a file format to use for these key pairs.

[Ballot discuss]
Hi Stephen,

Thanks for the effort put into this specification.

Please find below some few easy-to-fix DISUCSSion points:

# Missing normative references

## PEM-Encoded Grammar

CURRENT:
  The public and private keys MUST both be PEM encoded

Do we have a normative reference to characterize this requirements?

## PKCS#8 PrivateKey

CURRENT:
  The private key MUST be encoded as a PKCS#8 PrivateKey. 

## Can we cite Section 4 of [RFC4648] for the base 64 encoded part?

CURRENT:
  The public key(s) MUST be
  the base64 encoded form of an ECHConfigList value that can be

[Ballot comment]
# General

Consider adding a reminder that Section 4.1 of draft-ietf-tls-esni is authoritative for the config list and how this is used.

# Refresh

ECH spec says:

  A client-facing server has a set of known ECHConfig values, with
  corresponding private keys.  This set SHOULD contain the currently
  published values, as well as previous values that may still be in
  use, since clients may cache DNS records up to a TTL or longer.

How is this is supposed to work with the PEM format? Is there a need to tag the latest/current config vs. previous?

# Match

Section 3 says:

  When a private key is present, the ECHConfigList MUST
  contain an ECHConfig that matches the private key. 

What is meant here? How is that distinct from the following statement at the end of the same section:

CURRENT:
  Nonetheless, when a private key is present, that MUST
  match the public key from one of the ECHConfig values

# Multiple ECHConfig and order

CURRENT:
  The ECHConfigList in a PEM file might contain more than one ECHConfig
  if, for example, those ECHConfig values contain different extensions
  or different public_name values.

I guess the ECHConfig order is important here similar to this part from the ECH spec:

  The ECHConfigList structure contains one or more ECHConfig structures
  in decreasing order of preference.

If so, should that be clarified?

# Delimiter

The spec uses ECHCONFIG as delimiter, but refers to the delimited part as ECHConfigList such in the following:

Section 4:
  For clarity, only the ECHConfigList is to be published in the DNS -
  the private key from an ECH PEM file MUST NOT be published in the
  DNS.

I found the selected the delimiter and narrative text confusing.

# Nits

## Consider expanding ECH in the title.

# Section 3

OLD:
  If the ECHConfigList value is to be use as the retry_configs value

NEW:
  If the ECHConfigList value is to be used as the retry_configs value

Cheers,
Med

[Ballot comment]
Thank you for a clearly written document.

I have one comment which I think would be a useful addition: The current abstract doesn't say that this document specifies the format to be used to store the ECH keys. It would be good to a sentence saying this.

[Ballot comment]
Simple and straight to the topic draft, thanks for writing it.

Now, I have some comments:

1) why isn't this a TLS WG document ? I have read Sean Turner's explanation (thanks the shepherd's write-up), but this does not sound doing the 'right thing'. Anyway, this is IETF stream PS so all it good

2) the abstract is more like an introduction to the problem, it should really state the obvious (for completeness) "This document specifies the format used to store the keys"

3) explanation about the need for `BEGIN ECHCONFIG` rather than "BEGIN PUBLICKEY" would be welcome, I guess it allows for also having to store the public key in the same file for potentially other uses.

-éric

Request for IETF Last Call review by GENART Completed: Ready with Issues. Reviewer: Linda Dunbar. Sent review to list. Submission of review completed at an earlier date.

Request for IETF Last Call review by DNSDIR Completed: Ready with Issues. Reviewer: Jim Reid. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-01-01):

From: The IESG
To: IETF-Announce
CC: draft-farrell-tls-pemesni@ietf.org, paul.wouters@aiven.io, sean+ietf@sn3rd.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (PEM file format for ECH) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'PEM file format for ECH'
  as Proposed Standard

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 2026-01-01. 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


  Encrypted ClientHello (ECH) key pairs need to be configured into TLS
  servers, that can be built using different TLS libraries, so there is
  a benefit and little cost in documenting a file format to use for
  these key pairs, similar to how RFC7468 defines other PEM file
  formats.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-farrell-tls-pemesni/



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

# Document Shepherd Write-Up for Individual Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Was the document considered in any WG, and if so, why was it not adopted as a
  work item there?

This document was considered by the TLS WG. It was not adopted, much like
draft-josefsson-pkix-textual that was considered but not adopted by PKIX, because
the pem file formats to share are not really part of the protocol per se.

2. Was there controversy about particular points that caused the WG to not adopt
  the document?

There was zero controversy about this I-D.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize 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.)

No threat of appeal has been detected - and I would know ;)

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Here’s a list from Stephen’s slides @ IETF 124:

Produced/consumed by OpenSSL ECH feature branch
– https://github.com/openssl/openssl/tree/feature/ech

Bash script to produce using BoringSSL’s `bssl’:
– https://github.com/defo-project/ech-dev-utils/blob/nginx-pr/scripts/bssl2pem.sh

lighttpd: Jan 2025, just OpenSSL, partly done by me, partly by maintainer
– https://github.com/lighttpd/lighttpd1.4/commit/29da0e9861638e21c1cebdc354c68c347eaab0b2 and subsequent PRs

freenginx: Sep 2025, same 3 libraries, implementation by maintainer, not me
– https://freenginx.org/ Part of 1.29.2 release 2025-09-23

apache2 httpd: Sep 2025, just OpenSSL, upstreamed, not released
– https://github.com/apache/httpd/commit/0c9cd095ce9081fd225f0da7787419e80de7c701

haproxy: Oct 2025, just OpenSSL, merged upstream (2025-10-30)
– https://github.com/haproxy/haproxy/issues/1924#issuecomment-3438011449
– https://github.com/haproxy/haproxy/commit/dba4fd248a13fb0f3135619b14e3cf20b6674d10 part of haproxy 3.3-dev11

nginx: PR under discussion, BoringSSL or Op

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

No.

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

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] 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 [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

While there is no formal language to verify, I did verify that the examples
provided in ❡3 is in fact a PrivateKeyInfo.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

This document is r-e-a-d-y!

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document is intended for standard track. This is appropriate because you
do exchange this format. Also, it matches what was done for RFC 7468.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

I have confirmed with the authors that they have made the necessary disclosures.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

I have confirmed with the author that they are willing to be listed as such.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

No I-D nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

In version -10, I thought 7468 and 9460 should be informational. Stephen made
that change in -11 and now I think the I-D has the references categorized
correctly. I am also not willing to die on this hill so if the IESG has other
ideas - cool.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

I-D.ietf-tls-esni is a normative reference. As of 20251203, it is in AUTH48.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No.

20. 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 aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

I reviewed it. There are no actions and that is, in my opinion, correct.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/