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