[lamps] Re: Mohamed Boucadair's No Objection on draft-ietf-lamps-kyber-certificates-10: (with COMMENT)

[[e-mail]]

Hi Bas,

Thank you for the follow-up. The changes look good to me. Thanks.

Cheers,
Med

De : Bas Westerbaan <[e-mail]>
Envoyé : lundi 14 juillet 2025 16:53
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-lamps-kyber-certificates-10: (with COMMENT)






On 1 Jul 2025, at 11:28, Mohamed Boucadair via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Mohamed Boucadair has entered the following ballot position for
draft-ietf-lamps-kyber-certificates-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Sean, Panos, Jake, and Bas,

Thank you for the work put into this specification.

I trust the ASN module and examples were validated.

Please find below some comments, fwiw:

Thank you for your detailed comments.



# NIST Size Mapping

The ciphertext values in Table 1 do not match the ones used in Table 3 of
FIPS203. Is that intended?

Oops, that is indeed an error and has been corrected<https://github.com/lamps-wg/kyber-certificates/pull/127/commits/18f848556f5dcb78ae3674e9811a9af0f321d80b>.


# Redundant recommendation

We do say in Section 4:

  NOTE: While the private key can be stored in multiple formats, the
  seed-only format is RECOMMENDED as it is the most compact
  representation.

then restate in Section 6:

  When encoding an ML-KEM private key in a OneAsymmetricKey object, any
  of these three formats may be used, though the seed format is
  RECOMMENDED for storage efficiency.

and then in that same section:

  NOTE: While the private key can be stored in multiple formats, the
  seed-only format is RECOMMENDED as it is the most compact
  representation.

Unless there are subtleties I missed, these recommendations are identical to
me. Please keep one.

Removed one of the three occurrences. The remaining two (one of which isn't quoted in your mail) are technically different as one recommends the format for use within OneAssymetricKey object and the other for outside. [1]


# Notation

Please consider making this change in Section 5

OLD: id-alg-ml-kem-* in the SubjectPublicKeyInfo, then keyEncipherment MUST be

NEW: id-alg-ml-kem-* (where * is 512, 768, or 1024 - see Section 3) in the
SubjectPublicKeyInfo, then keyEncipherment MUST be

Done. [1]


# Operational Considerations

## The document includes a good discussion of operational guidance. Can we
please reorganize ops content similar to the structure followed recently in
draft-ietf-lamps-dilithium-certificates?

NEW:
  6.  Operational Considerations  . . . . . . . . . . . . . . . . .
    6.1. Private Key Format  (OLD: Section 6)
    6.2. Private Key Consistency Testing (OLD: Section 8)
    6.3. Serialization of Seed Values (OLD: Section 7)

Putting "private key format" under operational considerations doesn't seem right. In dilithium-certs it's also a separate section outside of operational considerations. To me grouping the remaining two subsections doesn't feel worthwhile. [1]


## On the encoding formats

As discussed, e.g., in [1], there might be some variation between the encoding
formats. I see serialization aspects are discussed in Section 7, but I wonder
whether we can include an explicit statement about the alignment (or
misalignment if any) about encoding approaches.

The private key format, and any context given in this I-D, has been a hotly debated topic.  Personally, I do not readily see an uncontroversial statement we could add, but I'm open to suggestions.



# Misc.

## Applicability: cite celi-wiggers-tls-authkem as an example

OLD:
  To be used in TLS, ML-KEM certificates
  could only be used as end-entity identity certificates and would
  require significant updates to the protocol; see
  [I-D.celi-wiggers-tls-authkem].

NEW:
  To be used in TLS, ML-KEM certificates
  could only be used as end-entity identity certificates and would
  require significant updates to the protocol; see, for example,
  [I-D.celi-wiggers-tls-authkem].

Done. [1]


## Should this be stated once rather than being repeated for each ASN snippet?

CURRENT:
     |  NOTE: The above syntax is from [RFC5912] and is compatible with
     |  the 2021 ASN.1 syntax [X680].  See [RFC5280] for the 1988 ASN.1
     |  syntax.

Left only one. [1]


## Please consider adding a citation in Section 4 to point to Appendix B. This
helpful to understand the values used in various snippets.

Done. [1]

## (nit) Missing "and" in Section 4

OLD:
  When an ML-KEM public key appears outside of a SubjectPublicKeyInfo
  type in an environment that uses ASN.1 encoding, it can be encoded as
  an OCTET STRING by using the ML-KEM-512-PublicKey, ML-KEM-
  768-PublicKey, ML-KEM-1024-PublicKey types corresponding to the
  correct key size.

NEW:
  When an ML-KEM public key appears outside of a SubjectPublicKeyInfo
  type in an environment that uses ASN.1 encoding, it can be encoded as
  an OCTET STRING by using the ML-KEM-512-PublicKey, ML-KEM-
  768-PublicKey, and ML-KEM-1024-PublicKey types corresponding to the
  correct key size.

Fixed. [1]


## (nit) an extra "the" in Section 4

OLD:
  When the ML-KEM private key appears outside of an Asymmetric Key
  Package in an environment that uses ASN.1 encoding, it can be encoded
  using one of the the ML-KEM-PrivateKey CHOICE formats defined in
  Section 6.

NEW:
  When the ML-KEM private key appears outside of an Asymmetric Key
  Package in an environment that uses ASN.1 encoding, it can be encoded
  using one of the ML-KEM-PrivateKey CHOICE formats defined in
  Section 6.

Fixed. [1]



## (nit) Section 6

OLD: a fixed 64 byte OCTET STRING (66 bytes total with

NEW: a fixed 64-byte OCTET STRING (66 bytes total with

Fixed. [1]



## (nit) Section 8

OLD: Private Key Consistency Tesing

NEW: Private Key Consistency Testing

Fixed. [1]



## Section 9

CURRENT:
  ML-KEM key generation as standardized in [FIPS203] has specific
  requirements around randomness generation, described in section 3.3,
  'Randomness generation'.

Please make it explicit this is about 3.3 of FIPS203.

Rephrased. [1]

Thanks again,

 Bas

[1] https://github.com/lamps-wg/kyber-certificates/pull/129



Thank you.

Cheers,
Med

[1] https://github.com/openssl/openssl/issues/26652 (bullet list with
seed-related discussion)



____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.