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]
