Subject: RE: Last Call Comments on CMS-10

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Tue, 12 Jan 1999 14:12:56 -0800

Russ:

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Tuesday, January 12, 1999 11:36 AM
> To: Jim Schaad (Exchange)
> Cc: Ietf-Smime (E-mail)
> Subject: Re: Last Call Comments on CMS-10
> 
> 
> Jim:
> 
> >1.  Section 2, Last paragraph, Sentence 4:  I think that 
> "However, signed
> >attributes within the signed-data content type and 
> authenticated attributes
> >within the authenticated-data content type require DER 
> encoding." should
> >read "However, signed attributes within the signed-data content type
> >andauthenicated a attributes within the authenticated-data 
> content type are
> >the only places where DER encoding is required."
> 
> I prefer:
> ...   However, signed attributes within the signed-data 
> content type and
> authenticated attributes within the authenticated-data 
> content type require DER
> encoding.  Signed attributes and authenticated attributes 
> must be transmitted
> in DER form to ensure that recipients can validate a content 
> that contains an
> unrecognized attribute.  Signed attributes and authenticated 
> attributes are the
> only CMS data types that require DER encoding.

This wording is great.

> 
> >3. The algorithm OIDs defined and used in section 12 are not 
> included in the
> >ASN module.
> 
> I know.  This is a philosophy question.  Since these identifiers will
> eventually be in the IANA registry, I did not know whether or 
> not these values
> should be part of the module.
> 
> I would be glad to add these values to the module if the 
> working group thinks
> they belong there.  Comments?
> 
> >4. Section 5, First pagagraph after the bullets.  The text 
> has not been
> >updated to reflect the SKI addition to the signer info object.
> 
> Good catch.  How about:
>    ...  The signer's public key is referenced by an issuer 
>    distinguished name along with an issuer-specific serial 
>    number or a subject key identifier that uniquely identify
>    the certificate containing the public key.
> 

Wording is good, but I would like "is referenced either by".

> >7.  Section 5.1: Text on version needs to be expanded to 
> deal with SKI.
> >Must be 3 if any SignerInfo version is 3.
> 
> Are you saying that a version 3 SignerInfo should cause 
> parent SignedData
> version to be 3?
> 
> Is there a reason to prohibit version 3 SignerInfo from being 
> encapsulated in a
> version 1 SignedData?

This is the backwards compatability thing.  Everywhere else we have done --
you get a new version all the way up (See EnvelopedData) if you do something
new on an inner object.  This prevents you from starting something you may
regret.  If we don't do this here, then I don't see why we should be doing
it in EnvelopedData.  I don't care which of the two we correct, but make
them consistant.

> 
> >10. Section 12.3.1, paragraph 3.  I would like to change the 
> first sentence
> >to "A CMS Implementation should support mixed key-encryption and
> >content-encryption algorithms."
> 
> Disgree.  I am reluctant to change "may" to "should."  What 
> do other people
> think?
> 
> >11. Section 12.3.3 - Please insert the following paragraph 
> in this section
> >"   A CMS implementation should support mixed key-encryption 
> and content-
> >   encryption algorithms.  For example, a 128-bit RC2 
> content-encryption
> >   key may be wrapped with 168-bit Triple-DES key-encryption key.
> >   Similarly, a 40-bit RC2 content-encryption key may be wrapped with
> >   128-bit RC2 key-encryption key."
> 
> As with comment 10, I would like to hear what other people 
> think before
> changing "may" to "should."

Can I at least get you to agree to put in the paragraph with the "may"
syntax even if I get no support for "should"?

> 
> >12. Ditto 11 for section 12.6
> 
> Ditto.  As with comments 10 and 11, I would like to hear what 
> other people
> think before changing "may" to "should."
> 

> Russ

jim

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Jan 1999 17:31:53 -0500

>Wording is good, but I would like "is referenced either by".

Here it is:
   ... The signer's public key is referenced either
   by an issuer distinguished name along with an
   issuer-specific serial number or by a subject key
   identifier that uniquely identifies the certificate
   containing the public key.  The signer's certificate
   may be included in the SignedData certificates field.

Russ