Hi David, Thank you for your reply. We have updated the files per your suggested text.
XML file: https://www.rfc-editor.org/authors/rfc9925.xml Output files: https://www.rfc-editor.org/authors/rfc9925.html https://www.rfc-editor.org/authors/rfc9925.pdf https://www.rfc-editor.org/authors/rfc9925.txt Comprehensive diff file of the text: https://www.rfc-editor.org/authors/rfc9925-diff.html https://www.rfc-editor.org/authors/rfc9925-rfcdiff.html (side by side) AUTH48 diff files: https://www.rfc-editor.org/authors/rfc9925-auth48diff.html (AUTH48 changes) https://www.rfc-editor.org/authors/rfc9925-auth48rfcdiff.html (AUTH48 changes side by side) https://www.rfc-editor.org/authors/rfc9925-lastdiff.html (last version to this one) https://www.rfc-editor.org/authors/rfc9925-lastrfcdiff.html (rfcdiff between last version and this) Now that we have received your final approval, we consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9925 Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time. Best regards, Alanna Paloma RFC Production Center > On Feb 20, 2026, at 1:13 PM, David Benjamin <[email protected]> wrote: > > Thanks! Took a closer look at the diff and I have one question (sorry, I > should have noticed this earlier). So the original draft-10 said: > > > For example, certification path validation (Section 6 of [RFC5280]) begins > > at a trust anchor, or root certification authority (root CA). > > The new one drops the comma and says: > > > For example, certification path validation (Section 6 of [RFC5280]) begins > > at a trust anchor or root certification authority (root CA). > > Looking at that, I realize this sentence was ambiguous. One can read it to > mean either of: > 1. Certificate path validation either begins at a trust anchor, or begins at > a root CA. > 2. Certificate path validation begins at a trust anchor. A trust anchor is > sometimes referred to as a root CA. > > The intent was the second one. In my eyes, the version without the comma > pushes it closer to the first interpretation. Though my English is not that > great, so I could just be wrong here. Does that match how you all read this? > If so, possibly we should write that sentence better. Perhaps... > > > For example, certification path validation (Section 6 of [RFC5280]) begins > > at a trust anchor, sometimes referred to as a root certification authority > > (root CA). > > Some background: The precise term to use is "trust anchor". That's the term > used in RFC 5280. Colloquially, people often say "root CA", in reference to > hierarchical PKI structure, where the "root CA" is configured as the trust > anchor. I've noticed in discussions that people get very confused when I say > "trust anchor" and mostly understand "root CA". (Even when they work in PKIs > that are not completely hierarchical!) So I thought it was worth briefly > clarifying that, when the document says "trust anchor", it corresponds to > what most people colloquially think of as a root CA. > > Other than that one question, the document looks good. Thanks! > > > On Tue, Feb 17, 2026 at 4:47 PM Alanna Paloma <[email protected]> > wrote: > Hi David, > > We have converted the kramdown-rfc file to RFCXML. > > Please review the XML file and its TXT, HTML, and PDF outputs, and let us > know if any changes are required or if you approve the RFC for publication. > While this is your approval of the XML and its outputs, we consider this your > final assent that the document is ready for publication. To request changes > or approve your RFC for publication, please reply to this email. Please use > ‘REPLY ALL’, as all the parties CCed on this message need to see your > approval. > > Note that we will only make changes in the XML file from this point on. > > XML file: > https://www.rfc-editor.org/authors/rfc9925.xml > > Output files: > https://www.rfc-editor.org/authors/rfc9925.html > https://www.rfc-editor.org/authors/rfc9925.pdf > https://www.rfc-editor.org/authors/rfc9925.txt > > Comprehensive diff file of the text: > https://www.rfc-editor.org/authors/rfc9925-diff.html > https://www.rfc-editor.org/authors/rfc9925-rfcdiff.html (side by side) > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9925 > > Thank you, > Alanna Paloma > RFC Production Center > > > On Feb 17, 2026, at 11:39 AM, David Benjamin <[email protected]> wrote: > > > > Thanks! The document looks good to me. > > > > > > > > On Fri, Feb 13, 2026 at 7:01 PM Alanna Paloma > > <[email protected]> wrote: > > Hi Deb, > > > > Thank you for confirming. We’ve noted your approval on the AUTH48 status > > page: > > https://www.rfc-editor.org/auth48/rfc9925 > > > > Best regards, > > Alanna Paloma > > RFC Production Center > > > > > On Feb 13, 2026, at 3:11 PM, Deb Cooley <[email protected]> wrote: > > > > > > The Appendix A sentence looks good. And the rest of the changes look > > > good too. > > > > > > Thanks, > > > Deb > > > > > > On Fri, Feb 13, 2026 at 3:08 PM Alanna Paloma > > > <[email protected]> wrote: > > > Hi David and Deb (AD)*, > > > > > > *Deb - As the AD, please review and approve of this added sentence in > > > Appendix A. > > > > > > Current: > > > This ASN.1 module uses the conventions established by [RFC5912]. > > > > > > See this diff file: > > > https://www.rfc-editor.org/authors/rfc9925-auth48diff.html > > > > > > > > > David - Thank you for the quick reply! We’ve updated the document > > > accordingly. > > > > > > The files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9925.txt > > > https://www.rfc-editor.org/authors/rfc9925.pdf > > > https://www.rfc-editor.org/authors/rfc9925.html > > > https://www.rfc-editor.org/authors/rfc9925.md > > > > > > The relevant diff files have been posted here (please refresh): > > > https://www.rfc-editor.org/authors/rfc9925-diff.html (comprehensive diff) > > > https://www.rfc-editor.org/authors/rfc9925-rfcdiff.html (side by side) > > > https://www.rfc-editor.org/authors/rfc9925-auth48diff.html (diff showing > > > AUTH48 changes) > > > https://www.rfc-editor.org/authors/rfc9925-auth48rfcdiff.html (side by > > > side) > > > > > > Markdown diffs: > > > https://www.rfc-editor.org/authors/rfc9925-md-diff.html > > > https://www.rfc-editor.org/authors/rfc9925-md-rfcdiff.html > > > https://www.rfc-editor.org/authors/rfc9925-md-auth48diff.html > > > https://www.rfc-editor.org/authors/rfc9925-md-auth48rfcdiff.html > > > > > > Please review the document carefully as documents do not change once > > > published as RFCs. We will await any further changes you may have and > > > approvals from you and *Deb (AD) prior to moving forward in the > > > publication process. > > > > > > For the AUTH48 status of this document, please see: > > > https://www.rfc-editor.org/auth48/rfc9925 > > > > > > For details of the AUTH48 process in kramdown-rfc (including the two-part > > > approval process), see: > > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc. > > > > > > Thank you, > > > Alanna Paloma > > > RFC Production Center > > > > > > > On Feb 12, 2026, at 4:04 PM, David Benjamin > > > > <[email protected]> wrote: > > > > > > > > Thanks! Responses inline. > > > > > > > > On Thu, Feb 12, 2026 at 6:33 PM <[email protected]> wrote: > > > > Authors, > > > > > > > > While reviewing this document during AUTH48, please resolve (as > > > > necessary) the following questions, which are also in the source file. > > > > > > > > 1) <!--[rfced] For clarity, may we update the latter part of this > > > > sentence > > > > as follows? > > > > > > > > Original: > > > > Senders MAY alternatively use a short placeholder issuer consisting > > > > of a single relative distinguished name, with a single attribute of > > > > type id-rdna-unsigned and value a zero-length UTF8String. > > > > > > > > Perhaps: > > > > Senders MAY alternatively use a short placeholder issuer consisting > > > > of a single relative distinguished name that has a single attribute > > > > of > > > > type id-rdna-unsigned and a value with a zero-length UTF8String. > > > > --> > > > > > > > > Hmm. This was meant to be read as "a single attribute with type X and > > > > value Y". X is "id-rdna-unsigned" and Y is "a zero-length UTF8String". > > > > > > > > Changing it to "with a zero-length UTF8String" reads a little odd > > > > because the zero-length UTF8String is the entire value. But I see where > > > > "and value a blah blah blah" reads a little funny. Would you all be > > > > happy with: > > > > > > > > Senders MAY alternatively use a short placeholder issuer consisting > > > > of a single relative distinguished name that has a single attribute > > > > with > > > > a type of id-rdna-unsigned and a value of a zero-length UTF8String. > > > > > > > > Or perhaps: > > > > > > > > Senders MAY alternatively use a short placeholder issuer consisting > > > > of a single relative distinguished name that has a single attribute: > > > > The > > > > attribute's type is id-rdna-unsigned, and its value is a zero-length > > > > UTF8String. > > > > > > > > Or perhaps: > > > > > > > > Senders MAY alternatively use a short placeholder issuer consisting > > > > of a single relative distinguished name that has a single attribute, > > > > whose > > > > type is id-rdna-unsigned and whose value is a zero-length UTF8String. > > > > > > > > Thoughts? > > > > 2) <!--[rfced] To improve readability and avoid the repetition of > > > > "include" and > > > > "includes", may we update this sentence as follows? > > > > > > > > Original: > > > > Section 4.2.1.1 of [RFC5280] requires > > > > certificates to include the authority key identifier, but includes an > > > > exception for self-signed certificates used when distributing a > > > > public key. > > > > > > > > Perhaps: > > > > Section 4.2.1.1 of [RFC5280] requires > > > > certificates to include the authority key identifier, but it also > > > > describes an > > > > exception for self-signed certificates used when distributing a > > > > public key. > > > > --> > > > > > > > > Works for me. An alternate suggestion: > > > > > > > > Section 4.2.1.1 of [RFC5280] requires > > > > certificates to include the authority key identifier, but it permits > > > > an > > > > exception for self-signed certificates used when distributing a > > > > public key. > > > > > > > > The immediately following sentence is "This document updates [RFC5280] > > > > to also permit omitting authority key identifier in unsigned > > > > certificates". Using the word "permit" in both cases seems to parallel > > > > nicely. > > > > > > > > Thoughts? > > > > 3) <!--[rfced] FYI - We've reformatted the following text into an > > > > unordered > > > > list. Please review and let us know of any objections. > > > > > > > > Original: > > > > Senders SHOULD fill in these values to reflect the subject. That is: > > > > > > > > If the subject is a CA, it SHOULD assert the keyCertSign key usage > > > > bit and SHOULD include a basic constraints extensions that sets the > > > > cA boolean to TRUE. > > > > > > > > If the subject is an end entity, it SHOULD NOT assert the keyCertSign > > > > key usage bit, and it SHOULD either omit the basic constraints > > > > extension or set the cA boolean to FALSE. Unlike a self-signed > > > > certificate, an unsigned certificate does not issue itself, so there > > > > is no need to accommodate a self-signature in either extension. > > > > > > > > Current: > > > > Senders SHOULD fill in these values to reflect the subject. That is: > > > > > > > > * If the subject is a CA, it SHOULD assert the keyCertSign key usage > > > > bit and SHOULD include a basic constraints extension that sets > > > > the cA boolean to TRUE. > > > > > > > > * If the subject is an end entity, it SHOULD NOT assert the > > > > keyCertSign key usage bit, and it SHOULD either omit the basic > > > > constraints extension or set the cA boolean to FALSE. Unlike a > > > > self-signed certificate, an unsigned certificate does not issue > > > > itself, so there is no need to accommodate a self-signature in > > > > either extension. > > > > --> > > > > Ah yeah, that's much better. Thanks! > > > > > > > > 4) <!--[rfced] To improve readability, may we update "etc." to "for > > > > example"? > > > > > > > > Original: > > > > However, some applications might use > > > > it as an integrity check to guard against accidental storage > > > > corruption, etc. > > > > > > > > Perhaps: > > > > However, some applications might, for example, use > > > > it as an integrity check to guard against accidental storage > > > > corruption. > > > > --> > > > > > > > > Yup, that reads better! Thanks! > > > > 5) <!--[rfced] We note that [RFC5912] is only cited in the ASN.1 > > > > module. > > > > In order to have a 1:1 matchup between the references section and the > > > > text, > > > > please review the text and let us know where a citation may be included. > > > > We suggest adding a sentence before the ASN.1 module to cite [RFC5912]. > > > > > > > > Perhaps: > > > > This ASN.1 module uses the conventions established by [RFC5912]. > > > > --> > > > > > > > > I don't know what the convention is here, so I'll defer to chairs and > > > > ADs. That seems reasonable to me? > > > > 6) <!-- [rfced] FYI - We have added an expansion for the following > > > > abbreviation > > > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > > > expansion in the document carefully to ensure correctness. > > > > > > > > Key Encapsulation Mechanism (KEM) > > > > --> > > > > > > > > That is a correct expansion. Thanks! > > > > 7) <!-- [rfced] Please review the "Inclusive Language" portion of the > > > > online > > > > Style Guide > > > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > > > and let us know if any changes are needed. Updates of this nature > > > > typically > > > > result in more precise language, which is helpful for readers. > > > > > > > > Note that our script did not flag any words in particular, but this > > > > should > > > > still be reviewed as a best practice. > > > > --> > > > > > > > > No changes for inclusive language needed that I can see. > > > > Thank you. > > > > > > > > Alanna Paloma > > > > RFC Production Center > > > > > > > > > > > > On Feb 12, 2026, at 3:31 PM, [email protected] wrote: > > > > > > > > *****IMPORTANT***** > > > > > > > > Updated 2026/02/12 > > > > > > > > RFC Author(s): > > > > > > > > Your document has now entered AUTH48. > > > > > > > > The document was edited in kramdown-rfc as part of the RPC pilot test > > > > (see > > > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc). > > > > > > > > > > > > Please review the procedures for AUTH48 using kramdown-rfc: > > > > > > > > https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_instructions_completing_auth48_using_kramdown > > > > > > > > Once your document has completed AUTH48, it will be published as > > > > an RFC. > > > > > > > > > > > > Files > > > > ----- > > > > > > > > The files are available here: > > > > https://www.rfc-editor.org/authors/rfc9925.md > > > > https://www.rfc-editor.org/authors/rfc9925.html > > > > https://www.rfc-editor.org/authors/rfc9925.pdf > > > > https://www.rfc-editor.org/authors/rfc9925.txt > > > > > > > > Diff file of the text: > > > > https://www.rfc-editor.org/authors/rfc9925-diff.html > > > > https://www.rfc-editor.org/authors/rfc9925-rfcdiff.html (side by > > > > side) > > > > > > > > Diff of the kramdown: > > > > https://www.rfc-editor.org/authors/rfc9925-md-diff.html > > > > https://www.rfc-editor.org/authors/rfc9925-md-rfcdiff.html (side by > > > > side) > > > > > > > > > > > > Tracking progress > > > > ----------------- > > > > > > > > The details of the AUTH48 status of your document are here: > > > > https://www.rfc-editor.org/auth48/rfc9925 > > > > > > > > > > > > Please let us know if you have any questions. > > > > > > > > Thank you for your cooperation, > > > > > > > > RFC Editor > > > > > > > > -------------------------------------- > > > > RFC9925 (draft-ietf-lamps-x509-alg-none-10) > > > > > > > > Title : Unsigned X.509 Certificates > > > > Author(s) : D. Benjamin > > > > WG Chair(s) : Russ Housley, Tim Hollebeek > > > > Area Director(s) : Deb Cooley, Paul Wouters > > > > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
