RFC 8410 §9 module omits keyUsage bits RFC 9295 §3 permits (Erratum 9045)

[kjanat]

RFC 8410's ASN.1 module states a narrower set of permitted keyUsage bits for an
X25519 or X448 certificate than the normative prose does. RFC Erratum
9045 is now published with status
Reported.

Status

• RFC Erratum 9045 against RFC 8410
  Section 9, Technical, was submitted and published on 2026-07-29. It is
  currently Reported, awaiting discussion and disposition by the IESG.
• The library follows the prose. See "What micro509 does" below.

The two statements

RFC 9295 Section 3, which replaces RFC 8410 Section 5:

If the keyUsage extension is present in a certificate that indicates
id-X25519 or id-X448 in SubjectPublicKeyInfo, then the following MUST
be present:

  keyAgreement

One of the following MAY also be present:

  encipherOnly
  decipherOnly

RFC 8410 Section 9, which RFC 9295 leaves untouched:

pk-X25519 PUBLIC-KEY ::= {
    IDENTIFIER id-X25519
    -- KEY no ASN.1 wrapping --
    PARAMS ARE absent
    CERT-KEY-USAGE { keyAgreement }
    PRIVATE-KEY CurvePrivateKey
}

pk-X448 carries the same CERT-KEY-USAGE { keyAgreement }. RFC 5912 defines
PUBLIC-KEY.&keyUsage as the set of bits legal for the key type, so the module
omits two bits the current normative text explicitly permits.

RFC 9295 replacing Section 5 and not Section 9 is what leaves the mismatch
standing across two documents rather than inside one.

Why the prose is the correct half

RFC 5280 Section 4.2.1.3 defines both bits only in the presence of keyAgreement:

The meaning of the encipherOnly bit is undefined in the absence of the
keyAgreement bit. When the encipherOnly bit is asserted and the keyAgreement
bit is also set, the subject public key may be used only for enciphering data
while performing key agreement.

A key agreement key is exactly where they are meaningful. RFC 5912's own
Diffie-Hellman, KEA, and elliptic-curve key agreement PUBLIC-KEY definitions
list keyAgreement, encipherOnly, and decipherOnly together.

The Edwards half of the same module supports reading this as an oversight:

pk-Ed25519 PUBLIC-KEY ::= {
    CERT-KEY-USAGE {digitalSignature, nonRepudiation, keyCertSign, cRLSign}
}

That is exactly the union of the Edwards clauses. The module tracks the prose for
the Edwards curves and not for the Montgomery ones.

Errata already on file

Neither of the adjacent entries covers this:

• 5696 (Held for Document Update, Section 5) asks for clarification of the
  certification authority key usage requirements around keyCertSign.
• 7384 (Verified, Section 9) adds the missing Ed448 signature and public key
  structures to the module.

What micro509 does

assertSafeCurveKeyUsage in src/x509/extensions.ts implements RFC 9295
Section 3, not the module:

• X25519 / X448: keyAgreement required
  (montgomery_key_usage_requires_key_agreement); digitalSignature,
  nonRepudiation, keyEncipherment, dataEncipherment, keyCertSign, and
  cRLSign refused (montgomery_key_usage_forbids_signature_bit); at most one
  of encipherOnly and decipherOnly, per "One of the following MAY also be
  present" (montgomery_key_usage_forbids_both_cipher_bits).
• Ed25519 / Ed448 end-entity: at least one of nonRepudiation,
  digitalSignature, cRLSign (edwards_key_usage_requires_signing_bit), and
  keyCertSign refused.
• Ed25519 / Ed448 certification authority: keyCertSign required
  (edwards_key_usage_requires_key_cert_sign), the other three optional.
• Both Edwards cases refuse keyEncipherment, dataEncipherment,
  keyAgreement, encipherOnly, decipherOnly
  (edwards_key_usage_forbids_agreement_bit).

A CRL issuer certificate is the case where cRLSign is the bit chosen, and a CRL
issuer that is also a CA is the CA case, so the two branches cover all four
paragraphs of RFC 9295 Section 3.

Adopting the module instead would mean refusing encipherOnly and decipherOnly
outright on these curves, against the current normative text. Not planned.

docs/rfc/rfc9295.txt is vendored. Coverage is in test/rfc/rfc8410.test.ts
under "5. Key Usage Bits".

Resolved

The library previously implemented the superseded RFC 8410 Section 5, which was
wrong in four ways now corrected:

	RFC 8410 §5	RFC 9295 §3
Ed end-entity	nonRepudiation, digitalSignature	adds cRLSign
Ed CA	any one of four bits	keyCertSign required, other three optional
Ed end-entity	keyCertSign accepted	refused
X25519 / X448	four signature bits refused	adds keyEncipherment, dataEncipherment

• RFC Editor entry: RFC Erratum 9045

[coderabbitai]

🔗 Related PRs

#2 - docs: trim fat from docs/, delete redundant ARCHITECTURE.md [merged]
#4 - refactor!: typed Result at trust boundaries (0.3.0) [merged]
#15 - 0.7.0 pre-1.0 API freeze cleanup (breaking) [merged]
#89 - fix(pem)!: OpenSSL header delimiter + audit citation sweep [merged]
#97 - fix: enforce RFC 7468, 8410, and 9295 conformance [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!