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

[Mohamed Boucadair via Datatracker <[e-mail]>]

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:

# NIST Size Mapping

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

# 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.

# 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

# 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)

## 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.

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

## 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.

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

## (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.

## (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.

## (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

## (nit) Section 8

OLD: Private Key Consistency Tesing

NEW: Private Key Consistency Testing

## 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.

Thank you.

Cheers,
Med

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