[Top] [All Lists]

Re: comments on draft-ietf-smime-cms-auth-enveloped-02

2007-03-19 03:12:26


Here is the first round of comments on this draft.

Thanks for your review.

1.  I would like to see all information about padding out to a block size
moved from this document to the algorithm documents.  This allows for each
algorithm to specify if padding is needed and what type of padding is

As an example, the CCM algorithm already as a padding technique built in and
therefore the padding is not needed, or is it?  I cannot tell from the
current documents if the data is supposed to be padded before it is passed
in or not.  Padding is properly a part of the algorithm processing and not
the superstructure processing.

The point is that some ciphers require the input to be a multiple of a block size. AES-CBC is one such cipher. We require that all such ciphers use the same padding mechanism in EnvelopedData. I thin that we want similar consistency in AuthEnvelopedDtata.

2.  If I implement a "stream" version of the decoder for authenticated data,
am I permitted to pass the decrypted data along prior to doing the
authentication step or not?   I raise the question because the CCM document

   The recipient MUST verify the CBC-MAC before releasing any
   information such as the plaintext.  If the CBC-MAC verification
   fails, the receiver MUST destroy all information, except for the fact
   that the CBC-MAC verification failed.

Which implies to me that until the validation is finished the decryption
code should not pass on any data but buffer it.

You read it correctly. Are you suggesting a change? I think that the current document is consistent with the AES-CCM and AES-GCM cipher descriptions.

3.  Just for clarity I think you need to state that you are not doing the
"change the '1' to Set" mess before passing the authenticated attributes
into the authentication algorithm.

I assume that this comment is about the tag. If so, please propose text for a "Note that ..." paragraph.

4.  Need to add text to state that each authenticated attribute must be
internally DER encoded as well as the set of attributes.

Since attributes doe not use the "octet hole" syntax, I am not sure why this is needed. Please explain.

5.  There is actually a downside to including the message-digest attribute.
It should be stated that this attribute MUST NOT be included.

These may be a performance downside, but I do not see a security one. Do you? If not, then I do not want to include a MUST NOT statement.

6.  I am having a problem understanding the text ins section 3 para 4.  When
using the symmetric key-encryption keys (and passwords) the actual AEK is
wrapped by the original key and thus would be a "one-time-use" key with just
as much certainty as for the key-transport method.  A better description of
the problem is needed here in order to fully justify what you are saying.

Yep, the current text is muddled.  I propose:

Fortunately, the CMS authenticated-enveloped-data content type provides all of the tools needed to avoid misuse of counter mode. All of the existing key management techniques permit a fresh content-encryption key to be generated for each content. In addition, existing authenticated encryption algorithms that make use of counter mode support the use of an unpredictable nonce value in the counter block. This unpredictable nonce value (sometimes called a "salt") should be carried in an algorithm identifier parameter.

7.  IANA section is missing

Ack.  I'll add one.


<Prev in Thread] Current Thread [Next in Thread>