[lamps] Re: I-D Action: draft-ietf-lamps-pq-composite-kem-12.txt

[Russ Housley <[e-mail]>]

I am concerned with this paragraph:

   *  *ECDH*: public key MUST be encoded as an uncompressed X9.62
      [X9.62_2005], including the leading byte 0x04 indicating
      uncompressed.  This is consistent with the encoding of ECPoint as
      specified in section 2.2 of [RFC5480] when no ASN.1 OCTET STRING
      wrapping is present.  The private key MUST be encoded as
      ECPrivateKey specified in [RFC5915] with 'NamedCurve' parameter
      set to the OID of the curve, but without the 'publicKey' field.
      The ciphertext MUST be encoded in the same manner as the public
      key.

The MUST statement refers to [X9.62_2005], which is not a readily available specification.

I suggest that the MUST statement point to Section 2.2 of [RFC5480], and then provide an informative statement that it is consistent with [X9.62_2005].  In this way, all normative references are publicly available.

Russ


> On Mar 9, 2026, at 5:07 PM, Russ Housley <[e-mail]> wrote:
> 
> Unused Reference to 'Aviram22'; please remove it.

> Obsolete informational reference to RFC 4210; it is Obsoleted by RFC 9810.
> 
> Obsolete informational reference RFC 5990; it is Obsoleted by RFC 9690.

> Reference to RFC 8411 should be informative, not normative.
> Russ
> 
> 
>> On Jan 7, 2026, at 11:50 PM, [e-mail] wrote:
>> 
>> Internet-Draft draft-ietf-lamps-pq-composite-kem-12.txt is now available. It
>> is a work item of the Limited Additional Mechanisms for PKIX and SMIME (LAMPS)
>> WG of the IETF.
>> 
>>  Title:   Composite ML-KEM for use in X.509 Public Key Infrastructure
>>  Authors: Mike Ounsworth
>>           John Gray
>>           Massimiliano Pala
>>           Jan Klaussner
>>           Scott Fluhrer
>>  Name:    draft-ietf-lamps-pq-composite-kem-12.txt
>>  Pages:   109
>>  Dates:   2026-01-07
>> 
>> Abstract:
>> 
>>  This document defines combinations of US NIST ML-KEM [FIPS.203] in
>>  hybrid with traditional algorithms RSA-OAEP, ECDH, X25519, and X448.
>>  These combinations are tailored to meet security best practices and
>>  regulatory guidelines.  Composite ML-KEM is applicable in any
>>  application that uses X.509 or PKIX data structures that accept ML-
>>  KEM, but where the operator wants extra protection against breaks or
>>  catastrophic bugs in ML-KEM.
>> 
>> The IETF datatracker status page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-lamps-pq-composite-kem/
>> 
>> There is also an HTMLized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-lamps-pq-composite-kem-12
>> 
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-lamps-pq-composite-kem-12
>> 
>> Internet-Drafts are also available by rsync at:
>> rsync.ietf.org::internet-drafts
>> 
>> 
>> _______________________________________________
>> Spasm mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>