Re: [Curdle] Review of draft-ietf-curdle-cms-ecdh-new-curves-03

[Russ Housley <[e-mail]>]

Jim:

Thanks for your note.  I missed these changes.  I will not post an updated draft until you confirm that this is aligned with draft-ietf-curdle-pkix.


> Section 3.2 - This section is wrong.  It is using the wrong structure.
> idecPublicKey is wrong.

I see that this needs to align with Section 3 of draft-ietf-curdle-pkix.

By the way, that section should drop the “(for the four EdDSA related OIDs)” since the document now only talks about the pure EdDSA version.

I removed the discussion if id-ecPublicKey and ECParameters.  That part of Section 3.2 in my edit buffer now says:

   The KeyAgreeRecipientInfo originator provides three alternatives for
   identifying the originator's public key, and the originatorKey
   alternative MUST be used.  The originatorKey MUST contain an
   ephemeral key for the originator.  The originatorKey algorithm field
   MUST contain the id-X25519 or the id-X448 object identifier.  The
   originator's ephemeral public key MUST be encoded as an OCTET STRING.

   The object identifiers for X25519 and X448 have been assigned in
   [ID.curdle-pkix].  They are repeated below for convenience.

   When using X25519, the public key contains exactly 32 octets, and the
   id-X25519 object identifier is used:

      id-X25519 OBJECT IDENTIFIER ::= { 1 3 101 110 }

   When using X448, the public key contains exactly 56 octets, and the
   id-X448 object identifier is used:

      id-X448 OBJECT IDENTIFIER ::= { 1 3 101 111 }


> These are all nice to haves, but I don't really care if they don't get done.
> 
> I would prefer that the check of the all-zero output in section 2.0 be a
> SHOULD rather than a MAY.

I changed MAY to SHOULD.

> Section 2 last paragraph - add network order to the string on representing
> the number

Done.  It now reads:

   The ECC-CMS-SharedInfo suppPubInfo field contains the length of the
   generated key-encryption key, in bits, represented as a 32-bit number
   in network byte order.  For example, the key length for AES-256 [AES]
   would be 0x00000100.

> Section 2.1 - I don't know if you should say that the left most bits of the
> result are used.  I know that is correct so I have a problem reading it any
> other way.

Done.  It now reads:

   To generate a key-encryption key (KEK), the KDF generates one or more
   KM blocks, with the counter starting at 0x00000001, and incrementing
   the counter for each subsequent KM block until enough material has
   been generated.  The 32-bit counter is represented in network byte
   order.  The KM blocks are concatenated left to right, and then the
   leftmost portion of the result is used as the pairwise key-encryption
   key, KEK:

      KM(i) = Hash(K || INT32(counter=i) || DER(ECC-CMS-SharedInfo))

      KEK = KM(counter=1) || KM(counter=2) ...


Russ