[lamps] Re: [Technical Errata Reported] RFC9935 (9020)

[Deb Cooley <[e-mail]>]

I agree.  Policy choices like that belong in a Certificate Policy or
Certification Practice Statement.

I've put this on my 'errata to handle' list.

Deb

On Sun, Jul 5, 2026 at 3:56 PM Kampanakis, Panos <[e-mail]> wrote:

> Although this proposal intuitively makes sense, that is to ensure the
> security level of the leaf public key matches at least the security level
> of the signing CA public key, this is not commonly following PKI practices.
> For example, there are frequent cases where the leaf chosen by the
> subscriber can be ECDSA P384 and the ICA signs with P256. It is impractical
> that say that the issuer will perform the check and deny issuing the leaf
> cert if the subscriber requested for a higher security public key /
> identity. The subscriber could perform this check and make its own informed
> decision, but the RFC does not add much value by bringing his up. Thus, I
> propose to not accept this Erratum.
>
> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Tuesday, June 30, 2026 10:31 AM
> To: [e-mail]; Massimo, Jake <[e-mail]>;
> [e-mail]; [e-mail]; Kampanakis, Panos <
> [e-mail]>; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [EXTERNAL] [lamps] [Technical Errata Reported] RFC9935 (9020)
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you can confirm the sender and know
> the content is safe.
>
>
>
> The following errata report has been submitted for RFC9935, "Internet
> X.509 Public Key Infrastructure - Algorithm Identifiers for the
> Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM)"
>
> --------------------------------------
> You may review the report below and at:
> https://errata.rfc-editor.org/eid9020/
>
> --------------------------------------
> Type: Technical
> Reported by: Abel C. H. Chen <[e-mail]>
>
> Section 9 says:
>
> Original Text
> -------------
> For more detailed ML-KEM specific security considerations regarding this,
> randomness, misbinding properties, decapsulation failures, key reuse, and
> key checks, refer to [ML-KEM-SEC-CONS].
>
> Corrected Text
> --------------
> For more detailed ML-KEM specific security considerations regarding this,
> randomness, misbinding properties, decapsulation failures, key reuse, and
> key checks, refer to [ML-KEM-SEC-CONS]. In the X.509 certificate, the
> digital signature should provide a security level equal to or higher than
> that of the KEM public key.
>
> Notes
> -----
> I have observed a potential issue in some application scenarios, where the
> public key in the certificate may use an ML-KEM-1024 public key, while the
> corresponding signature is generated using ML-DSA-44. This could lead to a
> situation in which a lower-security-level digital signature is used to sign
> or endorse a higher-security-level public key.
>
> In light of this, I would respectfully suggest considering an additional
> clarification in Section 9. Specifically, after the sentence: “For more
> detailed ML-KEM specific security considerations regarding this,
> randomness, misbinding properties, decapsulation failures, key reuse, and
> key checks, refer to [ML-KEM-SEC-CONS].”
>
> It may be helpful to add the following statement: “In the X.509
> certificate, the digital signature should provide a security level equal to
> or higher than that of the KEM public key.”
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". Please use "Reply All" to
> discuss whether it should be verified or rejected. When a decision is
> reached, the verifying party will log in to change the status and edit the
> report, if necessary.
>
> --------------------------------------
> RFC9935 (draft-ietf-lamps-kyber-certificates)
> --------------------------------------
> Title               : Internet X.509 Public Key Infrastructure - Algorithm
> Identifiers for the Module-Lattice-Based Key-Encapsulation Mechanism
> (ML-KEM)
> Publication Date    : March 2026
> Author(s)           : S. Turner, P. Kampanakis, J. Massimo, B. E.
> Westerbaan
> Category            : Proposed Standard
> Source              : lamps (sec)
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> Spasm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>