Private key compression

Composite-MLKEM-2024.asn

@@ -68,7 +68,7 @@ CompositeKEMPublicKeyOs ::= OCTET STRING (CONTAINING
 CompositeKEMPublicKeyBs ::= BIT STRING (CONTAINING 
                                 CompositeKEMPublicKey ENCODED BY der)
 
-CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey
+CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OCTET STRING
 
 CompositeCiphertextValue ::= SEQUENCE SIZE (2) OF OCTET STRING
 

draft-ietf-lamps-pq-composite-kem.md

@@ -659,8 +659,6 @@ Some applications may need to reconstruct the `OneAsymmetricKey` objects corresp
 
 Component keys of a CompositeKEMPrivateKey MUST NOT be used in any other type of key or as a standalone key.
 
-TODO - Delete This part
-Often, a `CompositePrivateKey` will be carried within a carrier format such as PKCS#8 which is itself a `OneAsymmetricKey` structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], then a situation arises where we have `CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey` inside another `OneAsymmetricKey`. On the outer `OneAsymmetricKey`, the `privateKeyAlgorithm` field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the `privateKey` field SHALL contain the `CompositeKEMPrivateKey`, and the `publicKey` field MUST NOT be present. As discussed in {{impl-cons-decaps-pubkey}}, the ML-KEM private key encoding already includes a copy of the public key, so the `publicKey` field of the first `OneAsymmetricKey` remains OPTIONAL. However, the public key of the traditional component, RSA or Elliptic Curve, is required as input to the KEM Combiner function, and is not typically carried within an RSA or Elliptic Curve private key. Therefore the `publicKey` field of the second `OneAsymmetricKey` MUST contain the corresponding public key. See {{impl-cons-decaps-pubkey}} for more discussion. Which `AlgorithmID`s to place into the component `OneAsymmetricKey`s is ambiguous; since `OneAsymmetricKey.PrivateKeyAlgorithmIdentifier.AlgorithmID` is not optional, producers MUST place something here and MAY either duplicate the composite AlgorithmID into both components, or MAY place the AlgorithmID of the component algorithm. Parsers SHOULD ignore the component private key `AlgorithmID`s and assume that the private keys are in the same order as specified in {{tab-kem-algs}}.
 
 ## Encoding Rules {#sec-encoding-rules}
 <!-- EDNOTE 7: Examples of how other specifications specify how a data structure is converted to a bit string can be found in RFC 2313, section 10.1.4, 3279 section 2.3.5, and RFC 4055, section 3.2. -->