[Plants] Re: Mohamed Boucadair's Block on charter-ietf-plants-00-02: (with BLOCK and COMMENT)

[David Benjamin <[e-mail]>]

Don't read much into the draft's classification. I suspect I set that
classification without thinking about it two years ago, likely by just
copying from another file I had. :-) I've just fixed it on GitHub to match
the draft charter.

The citation count is similarly misleading. As I said, the things it
imports normatively are foundational, so they would naturally be mentioned
throughout the document. And then there are plenty of non-normative
mentions because it discusses how the system compares throughout. I-Ds
don't classify  As you say, it may be difficult for an outsider to see
this, but, from the showing at the BoF, I'm confident we'll have plenty of
experts in the WG to navigate all this. (I can certainly say that I'll be
participating, and I would like to think I know a thing or two about this
space! ;-) )

I see also that both RFC 6962 and RFC 9162 are *already* in the downref
registry, so there is precedent for citing these documents. (Naturally so.
RFC 6962 is now a well-established part of some of the largest PKIX
deployments on the Internet.)
https://datatracker.ietf.org/doc/downref

And, of course, keep in mind that we are discussing a *charter* right now,
not the draft. Procedural issues around the final submitted documents can
be sorted out when we have documents to submit, and a working group to make
those documents. If we need to add to the downref registry, we can do that.
If we need to copy-paste Section 2.1 of RFC 9162 somewhere, we can do that
as well. None of that is enshrined in the charter. The charter discusses
RFC 6962 and RFC 9162 as they relate to the needs of the applications we
are serving.

Do you have remaining charter-blocking concerns about the statuses of RFC
6962 and RFC 9162 *as they relate to the charter*?

David

On Mon, Dec 15, 2025, 02:16 <[e-mail]> wrote:

> Hi David,
>
>
>
> Thank you for diving into details of various pieces.
>
>
>
> It is interesting to note though that draft-davidben-tls-merkle-tree-certs
> has +20 citations of 9162 and that it auto-classifies itself as
> Experimental. From an outsider, decorrelating matters that inherently
> depends on an Exp vs. those can be independently developed in a PS is not
> that trivial.
>
>
>
> Of course, and as you rightfully said, “WG consensus may always take the
> work in a different direction”, but I’m afraid these aspects seem to be
> frozen in the current charter version.
>
>
>
> No need to repeat that I’m fully supportive of this work :)
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* David Benjamin <[e-mail]>
> *Envoyé :* lundi 15 décembre 2025 00:34
> *À :* BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> *Cc :* The IESG <[e-mail]>; [e-mail]; [e-mail]
> *Objet :* Re: [Plants] Mohamed Boucadair's Block on
> charter-ietf-plants-00-02: (with BLOCK and COMMENT)
>
>
>
> Hi Mohamed,
>
>
>
> Thanks for the comments! Let me address the RFC 6962 vs RFC 9162 comment.
> It seems this comment is in part based on a misunderstanding, which I'll
> try to clarify here. The situation can be a bit confusing for folks who
> have not been following CT.
>
>
>
> Today, CT, in all its deployed forms, is based on RFC 6962. As far as I'm
> aware, there are zero implementations or deployments of RFC 9162. As you
> note, both documents are experimental. It seems the results of those two
> experiments were that RFC 6962 was deployed (and then refined, see below)
> and RFC 9162 was not.
>
>
>
> This includes the https://letsencrypt.org/2025/08/14/rfc-6962-logs-eol blog
> you mention.  Yes, it refers to sunsetting RFC 6962, viewed as a complete
> package, but the replacement is still broadly RFC 6962 and not RFC
> 9162. That blog is about the Static CT API. The Static CT API is an
> evolution, by the CT community, of RFC 6962's HTTP serving APIs. It does
> not apply any of the deeper, incompatible changes made in RFC 9162. The log
> contents, SCT construction, TLS integrations, certificate upload APIs,
> etc., in Static CT all follow RFC 6962 and not RFC 9162. (Following RFC
> 6962 was what allowed the Static CT API to be a small, incremental
> change, with only a few roles being updated. If the Static CT API were
> based on RFC 9162, it would have required ecosystem-wide changes.)
>
>
>
> Keep in mind also that RFC 9162 neither addressed the problems solved by
> the Static CT API, nor the problems we are aiming to address in PLANTS.
>
>
>
> Fortunately, this situation is unlikely to have any real impact on the
> PLANTS working group. The dispatched work
> (draft-davidben-tls-merkle-tree-certs[1]) restructures things in such a way
> that the differences between the two RFCs become moot. Indeed that
> restructuring is where the solutions to the chartered problems lie. The
> only normative citations to CT are:
>
>
>
> * The general problem space and roles surrounding transparent PKIs
>
> * The low-level Merkle Tree primitive
>
>
>
> These two are fairly foundational, and common to both RFC 6962 and RFC
> 9162. We cited the RFC 9162 formulation as it seemed simplest, but it's
> really the same. The WG can also easily copy the cited definitions if
> necessary for clarity, or to deal with minutia experimental vs
> standards-track. Of course, WG consensus may always take the work in a
> different direction anyway. Regardless, nitty-gritty details of
> document citations seem too fine a point to put into a WG charter.
>
>
>
> With that background, the charter opted to just cite both documents:
>
>
>
> 1. That text introduces the real-world applications that care about this.
> As those all use RFC 6962, it seemed important to cite what they actually
> use.
>
>
>
> 2. At the same time, RFC 9162 *does* obsolete RFC 6962, so it seemed
> important to cite it, both to acknowledge this other design, and to clarify
> that both RFC 6962 and RFC 9162 suffer equally from the chartered problems.
>
>
>
> 3. While one could spend several paragraphs discussing all this, that
> seems mostly a distraction. The status of the two documents is neither
> relevant to the chartered problem (both documents are equally impacted) nor
> the initial solution, so we opted to just acknowledge both and move on.
>
>
>
> Hope that helps clarify things! Given all that, my feeling is that we
> should keep this part of the charter as-is. (Any thoughts from our
> AD, chairs, etc.?)
>
>
>
> David
>
>
>
> [1] The draft name says "tls" due to how the work first evolved years ago.
> It's not TLS-specific anymore.
>
>
>
> On Sun, Dec 14, 2025 at 7:11 AM Mohamed Boucadair via Datatracker <
> [e-mail]> wrote:
>
> Mohamed Boucadair has entered the following ballot position for
> charter-ietf-plants-00-02: Block
>
> 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.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-plants/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> Hi all,
>
> I’m definitely supportive of this work which addresses a real operational
> need.
> I also like the phased approach to first focus on the main building blocks
> is
> pragmatic.
>
> I will be balloting YES, but I would like to discuss one point first:
>
> # Intended Status of main Deliverable
>
> The work is anchored on CT per this part in the charter:
>
> CURRENT:
>   The goal of the PLANTS Working Group is to trim the costs of large
>   post-quantum signatures on PKIs with Certificate Transparency (CT; RFC
> 6962
>   and RFC 9162),
>
> RFC 6992 is obsoleted and plans of its end of use was disclosed such as in
> [1].
>
> RFC 9162 is published as Experimental, which questions the intended status
> of
> the main outcome per:
>
> CURRENT:
>   Submit a standards document defining the mechanism described in the
> charter.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Two or three items
>
> CURRENT:
>    Overhead from post-quantum signatures and keys will add significant
> costs in
>    two ways:
>
> ..but then three bullet items are listed. Please double check.
>
> # Too verbose
>
> CURRENT:
> Though not the initial focus, the PLANTS Working Group may consider other
> properties of transparent PKIs to improve upon the status quo, such as
> auditing, monitoring, or revocation. If feasible concrete improvements are
> identified, the Working Group may recharter to seed secondary deliverables
> that
> build on its initial work.
>
> Can be shortened to:
>
> NEW:
> Means to improve auditing, monitoring, and revocation are out of scope.
>
> # Better flow
>
> The text starting with “In evaluating decisions and design tradeoffs” is
> better
> positioned right after the 3 bullet work items.
>
> # One or multiple main deliverables
>
> For better flexibility, and putting aside the intended status, it may be
> better
> to leave room for the WG to decide whether all pieces need to be in one or
> multiple documents:
>
> OLD:
>   * Submit a standards document defining the mechanism described in the
> charter
>
> NEW:
>   * Submit *** document(s) defining the mechanism described in the charter
>
> Cheers,
> Med
>
> [1] https://letsencrypt.org/2025/08/14/rfc-6962-logs-eol
>
>
>
> _______________________________________________
> Plants mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>