Subject: Re: Comments on draft-ietf-smime-cms-aes-cmc-and-gcm-00.txt

From: Russ Housley <[email-masked]>
Date: Tue, 20 Mar 2007 10:50:22 -0400

Jim:

>1.  Pointer to GCM is out of date.  Should be
>http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/gcm-revised-spec.pdf

They are compatible, but I'll change the reference.  I hope that the 
NIST SP comes out before this document is published as an RFC.

>2.  I don't see CCM as having two outputs, the text appears to imply that
>the authentication code is emitted as part of the encrypted message stream
>rather than separately [RFC 3610 section 2.4].  This contradicts what is
>stated in section 1.4 of this document.

RFC 3610 says that the final result consists of the encrypted message 
followed by the encrypted authentication value.  This is a result of 
the packet-oriented description that we use in that 
document.  Section 2.5 talks about the inputs to the decrypt and 
authentication checking function, and this section says: "Decryption 
starts by recomputing the key stream to recover the message m and the 
MAC value T."  In the AuthEnvelopedData syntax, these two things are 
carried in two different fields, but the key stream is used as 
described in CCM to perform the decryption.  In fact, the counters 
that are used makes this simple and straightforward.  Counter value 0 
is used for the MAC, and counter values 1 .. n are used for the content.

>3.  Neither of the algorithms discusses what is needed for padding.

Due to the ASN.1 encoding, all inputs are guaranteed to be multiples 
of octets.  No padding of the inputs is needed.

Russ