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]
