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 <davidben= > [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]
