Subject: RE: Comments on CMC-09

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Mon, 30 Nov 1998 13:38:21 -0800

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, November 25, 1998 11:29 AM
> To: Jim Schaad (Exchange)
> Cc: [email-masked]
> Subject: Re: Comments on CMC-09
> 
> 
> Jim:
> 
> >4.  Section 4.0 Last Paragraph:  Please delete the last 
> sentence in this
> >paragraph.  I don't understand what is going on in this 
> paragraph.  We have
> >obously defined how to do the encapsulated content in this 
> document (such as
> >signed data in signed data), we just have not defined any 
> other base content
> >types 
> 
> Agree.  This was intended to allow arbitrary content types to 
> be encapsulated. 
> I agree that it does not belong in this section.  Does the 
> thought belong
> somewhere else?
> 
> Also, I added the Data ASN.1 definition:
> 
>   The data content type shall have ASN.1 type Data:
> 
>         Data ::= OCTET STRING
> 

I agree with the addition of the ASN.  I don't think the thought needs to be
expressed anyplace else.  Neither of the sections for encapsulated or
enveloped content have any restrictions implied or explict about the content
to be encapsulated.
> 
> >5.  Section 2.0 Paragraph 1.  Change "ContentInfo 
> encapsulates one or more
> >content types." to "ContentInfo encapsulates an identified 
> content type."
> >There is no sequence so the one or more is misleading.
> 
> I agree with your point.  How about:
> 
>    ContentInfo encapsulates a single identified content type, and
>    the identified type may provide further encapsulation.
> 

This sounds fine with me.

> 
> >6.  Section 3.0  Should we change the title on this section 
> from General
> >Syntax to Content Info?  Since we are no longer restricting 
> the exported
> >types to ContentInfo then there is no longer a single general syntax
> >anymore.
> 
> This is the title used by PKCS#7 v1.5.  My hope is to make it 
> easier for the
> reader who is concerned about backward compatibility.
> 
> What do other people think about this one?
> 
> 
> >9.  Section 9.2:  Was there a reason for removing the 
> "rather than the
> >implcit [0] .." phrase.  This exists in the process for 
> signed data and I
> >think should be here as well.
> 
> For authenticated-data, digests are only computed on the 
> content.  They are
> never computed on the attributes.  The IMPLICIT [0] stuff was 
> about the
> attribute encoding.
>

I don't follow your response.  What I am looking at is the text relating to
the creation of the authenticatedAttributes blob over which the MAC will be
computed.  This is yet another location where the ASN which is encoded and
sent is not the same as the ASN which is acutally MAC-ed.  I think this
should be very explicit like in the other cases.
 
> 
> >10.  Global -- You have some inconsitant labeling  Some 
> references are
> >bracked and some are not.  Please go through the document 
> and choose one
> >method or the other but be consistant.  (Examples are 11.0 
> uses brackets but
> >10.2.2 does not.)
> 
> I changed 10.2.2.  I did not see any others like that one.
> 

I'll send you a list.

> 
> >13.  Section 12.3.1.1 Para "keyEncryptionAlgrothm must ..." 
> I have a problem
> >with the phase a "and contain a", the first 6 or 7 time I read this I
> >assumed it was a field in the parameters rather than being 
> the parameter
> >itself.  Writing as "The algorihtm identifier parameter field for
> >id-alg-ESDH is KeyWrapAlgorihtm and must be present." avoids 
> this issue.
> 
> Okay.  How about:
> 
>    The algorihtm identifier parameter field for id-alg-ESDH
>    is KeyWrapAlgorihtm, and this parameter must be present.
>
This is just fine.
 
> 
> >14.  Section 12.3.3 Last paragarph.  What is this paragraph 
> doing here?  It
> >is talking about key agreement in the symetric key 
> -encryption section.
> 
> The output of a key agreement algorithm is a key-encryption 
> key, and this
> key-encryption key is used to encrypt the content-encryption 
> key.  The last
> paragraph is a backward pointer telling folks that the same 
> techniques are used
> regardless of the source of the key-encryption key.  I will 
> add an sentence to
> the front of this paragraph that hopefully makes this more clear.
> 
I don't understand this even with your explination.

> 
> >15.  Section 12.6.2 - You have not modified the key wrap 
> algorithm to allow
> >for arbitrary length RC2 key sources.
> 
> Are you suggesting an explicit length field or something else?
> 
We need to either put in an explicit length field or use a known padding
algorithm.  I have no perference on which is used but something along this
lines is absolutely required.

> 
> >16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV 
> present and is its
> >value the constant 'A5' repeated n time?  The IV was not 
> present in the
> >previous versions but would appear to be present now.  We 
> still have the IV
> >restriction on the key wrap algorithm however.
> 
> There is no field needed to carry the IV as it is always 
> "A5...A5".  For 3DES,
> the parameter is always NULL, and for RC2 the parameter is 
> the effective key
> length.  Where do you see an IV?

OK -- I see where I got confused.  I started with the second paragraph in
section 12.3.1 and made a leap of incorrectness into the fact that the
KeyWrapAlgorithm was going to be rc2-cbc not id-alg-RC2wrap.  I don't see
any clarifications that need to be added to the text, I was just skimming
the changes too fast.

> Russ

jim

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 01 Dec 1998 00:45:29 +0000

> lines is absolutely required.

Speaking personally I'd prefer known padding. Known padding at least
adds some consistency with the use of symmetric algorithms: they all use
the "padded" forms.

If an explicit length parameter is included the logical place to put it
is in the EncryptedContentInfo structure because its a property of the
content encryption key. You'd probably then have to make it OPTIONAL for
v2 compatability only include it when at least one recipient used key
agreement.

With known padding the following minor change should suffice:

   1.  Modify the content-encryption key to meet any restrictions on 
       the key. For example, adjust the parity bits for each DES key
       comprising a Triple-DES key.
   2.  Compute a 16-bit key checksum value on the content-encryption key
       as described above.
   3.  Generate a 32-bit random salt value.
   4.  Concatenate the salt, content-encryption key, and key checksum
       value.
   5.  Add one block length of randomly generated pad octets. Then pad
       the result using standard block padding as defined in section
       6.3.
   6.  Encrypt the result with the key-encryption algorithm key.  Use an
       IV with each octet equal to 'A5' hexadecimal.

The unwrap text is OK as it is but a comment could be added that the
key length can be checked:

   5.  If there are restrictions on keys, then check if the
       content-encryption key meets these restrictions.  For example,
       check for odd parity of each octet in each DES key that makes up
       a Triple-DES key and check that the key length is correct.  If 
       any restriction is incorrect, then there is an error.

> any clarifications that need to be added to the text, I was just skimming

Just to add a little comment of my own since I suggested part of this.
My primary reason for this change is to allow algorithms other than RC2
and 3DES to be used with key agreement. In the case of RC2 and 3DES a
special algorithm identifier form is defined without the IV. In other
cases, such as (single) DES the normal algorithm identifier would be
used which would include an IV: but in this case it would be ignored
and A5 used.

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.