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]
