OASIS Open

Individual

Yes

I'm assuming these can be handled as editorial fixes - they don't gate my vote:

In 1.1.2 the document has 0 < ulCounterBits <= 128, but later in that section has "This construction permits ... up to 2^32-1...". One of these is wrong as you can't have more blocks than the block counter max value.

Both CCM and GCM should probably use the NIST documents as the reference rather than the RFCs.

For CCM, if the counter block format is as defined in appendix A of the NIST document (and it appears to be given the format of the input structure), state that. The base document allows alternate formats, but appendix A is not part of the main standard.

In 1.2.4, in the last bullet under Encrypt the document has C_DecryptUpdate where it should be C_EncryptUpdate.

Finally, if either CCM or GCM prohibits release of data before the MAC tag is checked, it would be useful to state a suggested minimum buffering size. The number I got from Russ Housley was 2x the size of a jumbogram - call it 20K bytes. That may be more a more appropriate statement for a usage guide and does not gate my vote. If that's where this ends up I'd also note that CCM and GCM are designed for data where the length of the data is known specifically packetized network data. From a hardware implementation point of view, I'd probably end up not doing GCM and CCM in hardware due to this buffering requirement - instead doing it as a wraparound to ECB.