I started reading this 71 page document about conventions in X.509 Public Key Infrastructure. However, the body of the text was a lot less (11 pages) and i found it well written.

Thank you for this nice writeup

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)

Testing.

```
8.  Private Key Consistency Tesing
```

Thank you to Mallory Knodel for the GENART review.

Thanks for the work done in this document (and caring for very detailed appendixes). 

Just one minor comment about the abstract, it should use the verb "specify" and not "describe" as the status is intended standard (the introduction section does it well though).