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]
