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.
-->
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.
-->
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.
-->
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.
-->
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].
-->
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)
-->
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.
-->
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]
