Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Jul 2001 14:49:42 -0700

I have no problems with any of John's comments.

jim

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Pawling, John
> Sent: Wednesday, June 27, 2001 12:50 PM
> To: [email-masked]
> Subject: RE: Comments: draft-ietf-smime-rfc2630bis-00
> 
> 
> 
> All,
> 
> I agree with the majority of Jim's comments and Russ' 
> responses.  I have a
> few comments regarding their statements.  My comments are numbered
> consistently with Jim's original message.   
> 
> 
> 14) Section 5.3, SignerInfo signature description:  Jim 
> stated: "I don't
> understand the MUST in this paragraph.  The field is not 
> optional how can it
> be omitted?  The MUST is redundant."  I agree with Jim.  Recommend the
> following replacement:
> 
> OLD: [*** NEW ***] This field MUST be present; however, the 
> details of the
> signature
>      depend on the signature algorithm employed.
> 
> NEW: [*** NEW ***] The details of the signature depend on the 
> signature
> algorithm employed.
> 
> 
> 21) Section 6.1, EnvelopedData:  I agree with Jim's recommendation as
> follows: "Should change the ASN to "RecipientInfos ::= SET 
> SIZE (1..MAX) OF
> RecipientInfo" to reflect the MUST in the text?"
> 
> 
> 25) Section 6.2.1, KeyTransRecipientInfo rid description: Jim 
> proposed:
> "Alternative:  "Implementations MUST support both alternatives for
> specifying the recipient's certificate when decoding.  
> Implementations MUST
> support one of these alternatives for encoding."  Recommend 
> changing second
> sentence to: "Implementations MUST support at least one of these
> alternatives for encoding.".
> 
> 
> 27) Section 6.2.2, KeyAgreeRecipientInfo ukm description: Jim 
> stated: "I
> believe this is a MUST not a SHOULD statement."  Recommend 
> the following
> replacement:
> 
> OLD:  [*** NEW ***] Implementations SHOULD support UKM
>       processing.  Implementations that do not process UKMs MUST
>       gracefully handle the presence of UKMs.
> 
> NEW:  [*** NEW ***] Implementations MUST support ASN.1 decoding a 
> 	KeyAgreeRecipientInfo SEQUENCE that includes a ukm field.
> 	Implementations that do not fully support the processing of
> 	UKMs MUST gracefully handle the presence of UKMs.  
> 
> 
> 29) Section 6.3 Content-encryption Process, paragraph 2:  Jim 
> Proposed: "The
> input to the content-encryption process is the "value" of the 
> content being
> enveloped.  The resulting value of the encryption process is 
> then wrapped in
> an OCTET string for transporting."  I believe that this 
> paragraph should be
> deleted because it is redundant to the first paragraph in 
> section 6.3.  
> 
> 
> 36) Section 11.1 Content Type:  Jim proposed: "Content-type 
> MUST be omitted
> when building counter signatures."  I agree with Jim.  Recommend the
> following re-wording of his proposal be added as the last 
> sentence of the
> 1rst paragraph: "The content-type attribute MUST be omitted 
> when used as
> part of a countersignature unsigned attribute as defined in 
> section 11.4."
> 
> 
> 39) Section 11.3 Signing Time:  Jim stated and Russ agreed: 
> "I think we
> should loosen up the locations allows for signing-time.  I 
> would like to see
> it allowed as an autenticated attribute."
> I don't object to this change.  If the change is made, please make the
> following replacement:
> 
> OLD: The SignedAttributes syntax is defined as a SET OF 
> Attributes.  The
>      SignedAttributes in a signerInfo MUST not include 
> multiple instances
>      of the signing-time attribute.
> 
> NEW: The SignedAttributes and AuthAttributes syntaxes are 
> each defined as
>      a SET OF Attributes.  The SignedAttributes in a 
> signerInfo MUST NOT
>      include multiple instances of the signing-time 
> attribute.  Similarly,
>      the AuthAttributes in an AuthenticatedData MUST NOT 
> include multiple
>      instances of the signing-time attribute.
> 
> 
> 43) Section 11.4 Countersignature:  Jim stated "Item 1 in the values.
> Change to "... but MUST NOT contain a content-type attribute. 
> (No content
> type has been defined for a counter-signature.)"  Recommend 
> the following
> replacement:
> 
> OLD:  1.  The signedAttributes field MUST contain a message-digest
>       attribute if it contains any other attributes, but need not
>       contain a content-type attribute, as there is no 
> content type for
>       countersignatures.
> 
> NEW:  1.  The signedAttributes field MUST contain a message-digest
>       attribute if it contains any other attributes.
> 
> 	2.  The signedAttributes field MUST NOT contain a content-type
> 	attribute, because there is no content type for 
> countersignatures.
> 
> 
> ===========================================
> John Pawling, [email-masked]
> Getronics Government Solutions, LLC
> ===========================================
>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 3 Jul 2001 15:17:00 -0700

Russ,

Here are my responses, where an item is omitted you can assume that I agree
with your resolution.

>
> > > >1.  "The CMS ..." should be uniformly changed to "CMS ...".
> > > I think that "The Cryptographic Message Syntax (CMS) ..."
> is correct.  Are
> > > there places that I omitted "the"?
> >
> >Actually I have no problems with "The Crryptographic Message
> Syntax (CMS)".
> >However as I look at the abstract for draft -00, the second
> paragraph starts
> >"The CMS is derived from PKCS#7 ..."  In doing searches of
> the draft the
> >phrase "the CMS" is quite common.  I count 5 that should be altered.
>
> Okay.  I added "the" in the places that seems appropriate.

I will need to read what you did.  I was actully asking for "the" to be
omitted. I think that "The CMS" is incorrect.

> > > >16) Section 5.3, para "attrValues":  Append the
> following sentence.
> > > >"attrType may impose additional restrictions on the
> number of items in the
> > > >set."
> > >
> > > How about:
> > >
> > >     attrValues is a set of values that comprise the
> attribute.  The
> > >     type of each value in the set can be determined uniquely by
> > >     attrType.  The attrType MAY impose restrictions on
> the number of
> > >     items in the set.
> >
> >I think this should be may not MAY as there is no protocol
> statement at this
> >point.  If you want one then it should be "Signatures MUST
> fail verification
> >if any restrictions on the number of items in the set, imposed by an
> >attrType definition, are not met."
>
> Agree, the "MAY" should be "can".
>
> I go not agree with the MUST statement that you suggest.  To
> enforce this,
> a recipient must know all possible OIDs and the restrictions
> associated
> with them.
>
> The text now reads (I provided a bit more surrounding text
> for context):
>
>     The fields of type SignedAttribute and UnsignedAttribute have the
>     following meanings:
>
>        attrType indicates the type of attribute.  It is an object
>        identifier.
>
>        attrValues is a set of values that comprise the attribute.  The
>        type of each value in the set can be determined uniquely by
>        attrType.  The attrType can impose restrictions on the
> number of
>        items in the set.

Can we add the statement about failing verification to the attributes that
we have defined where it make sense?  I think that if there are two
content-type or two message-digest attributes that the verification process
really needs to fail.  I am more unsure what should be done for other
attributes as you are correct that an exhaustive set would be required to
verify.  Let me think about this issue.

> > > >25) Section 6.2.1, para "rid": Two items
> > > >a)  do we want to change to text to allow for SKI's to be
> > non-certificate based.
> >[Snip]
> >
> > > >c)  do we need to support both for specifying the
> certificate or just for
> > > >locating a certificate? (i.e. encode vs decode)
> > >
> > > We need both (for send and receive).  I prefer the
> subject key identifier;
> > > it is smaller.  However, S/MIME v2 requires issuer and
> serial number, which
> > > is bigger than a subject key identifier.  If you do not
> think that the MUST
> > > statement is complete, please propose an alternative.
> >
> >Alternative:  "Implementations MUST support both
> alternatives for specifying
> >the recipient's certificate when decoding.  Implementations
> MUST support one
> >of these alternatives for encoding."
>
> John Pawling said: Recommend changing second sentence to:
> "Implementations
> MUST support at least one of these alternatives for encoding.".
>
> In an attempt to use the same terminology as the rest of the
> paragraph, I
> prefer "recipient processing" to "decode" and "sender
> processing" to "encode."
>
> How about:
>
>        rid specifies the recipient's certificate or key that
> was used by
>        the sender to protect the content-encryption key.  The
>        RecipientIdentifier provides two alternatives for
> specifying the
>        recipient's certificate, and thereby the recipient's
> public key.
>        The recipient's certificate MUST contain a key transport public
>        key.  The content-encryption key is encrypted with the
> recipient's
>        public key.  The issuerAndSerialNumber alternative
> identifies the
>        recipient's certificate by the issuer's distinguished
> name and the
>        certificate serial number; the subjectKeyIdentifier
> identifies the
>        recipient's certificate by the X.509 subjectKeyIdentifier
>        extension value.  [*** NEW ***] For recipient processing,
>        implementations MUST support both of these alternatives for
>        specifying the recipient's certificate; and for sender
> processing,
>        implementations MUST support one at least of these
> alternatives.

I would have liked to allow for SKI to be used in a non-certificate
environment, but I don't have any problems with the updated text.

>
> > > >27) Section 6.2.2, para "ukm":  I believe this is a MUST
> not a SHOULD
> > > >statement.  I understand that we don't require it for the default
> > algorithm
> > > >(ESDH), but it is premitted to occur.  If UKM is not
> supported then
> > all that
> > > >could be done would be to ignore the recipient.  (Note:
> there is a
> > MUST use
> > > >UKM in rfc2631 for one case.)
> > >
> > > UKM is required for Static-Static Diffie-Hellman.  I
> basically agree with
> > > your point, and it is not a big burden on an
> implementation. However, I
> > > would like to hear from more implementors before I make a
> change here.
> >
> >John - please respond.
>
> John Pawling said: Recommend the following replacement:
>
> processing.  Implementations that do not process UKMs MUST gracefully
> handle the presence of UKMs.
>
> Implementations
> that do not fully support the processing of UKMs MUST
> gracefully handle the
> presence of UKMs.
>
> Thanks John.  Again, in an attempt to use common terminology, I prefer
> "recipient processing" to "decode."  How about:
>
>        ukm is optional.  With some key agreement algorithms,
> the sender
>        provides a User Keying Material (UKM) to ensure that a
> different
>        key is generated each time the same two parties generate a
>        pairwise key.  [*** NEW ***] Implementations MUST support
>        recipient processing of a KeyAgreeRecipientInfo SEQUENCE that
>        includes a ukm field.  Implementations that do not support key
>        agreement algorithms that make use of UKMs MUST
> gracefully handle
>        the presence of UKMs.

I agree with the update.

>
> > > >28) Section 6.3.  Lets seperate the discussion on how to
> pad from the
> > > >content encryption process.  I believe this should be
> moved to the
> > algorithm
> > > >section or a seperate section in this document.  The CEK
> algorithm is what
> > > >determines the padding method not CMS.
> > >
> > > Not true.  CMS encryption always uses this padding.  CMS
> also supports
> > > algorithms that do not require any padding (for example,
> a stream cipher),
> > > but if padding is needed, this is the padding technique
> that MUST be used.
> >
> >I beg to differ with you on this issue.  I believe that I
> could define a new
> >OID for RC5 with Ron's funky padding mode where the cipher
> text and plain
> >text are the same lengths.  More importantly, with some of
> the new chaining
> >modes for AES where there is interleaving between mutiple
> chains, I can see
> >the padding to be done over a multiple of n blocks of data
> rather than one.
> >I repeat, the padding alogorithm is a fucntion of the
> specified encryption
> >algorithm and is not fixed.
>
> You have not convinced me.  The way that I read the RFC 2630
> text, we are
> saying that if padding is needed, then this one padding
> technique must be
> used.  If no padding is needed, as is the case if Triple-DES
> CFB8 is used,
> then no padding is present.  If one of the proposed AES modes
> that provide
> integrity and confidentiality were employed, the value of k
> might not match
> the AES block size, but padding is still needed.
>
> Right now, if padding is needed, we have one and only one way
> to do it.  I
> want to preserve this feature.  In my view, support for other padding
> approaches will only lead to more ways to fail interoperability.
>
> If you still feel strongly about this one, please start a
> separate thread
> for the discussion.

You have not convinced me, but I will think about this.

>
> > > >29) Section 6.3, para 2:  I don't like the second
> sentence in this
> > > >paragraph.  The content begin encrypted has little or
> nothing to do
> > with the
> > > >value of the encrypted data octet string.  This is the
> post encryption
> > > >value.
> > >
> > > I understand your point.  These words have not changed in
> a very long
> > > time.  Perhaps you would like to propose some better ones.
> >
> >Proposal:  "The input to the content-encryption process is
> the "value" of
> >the content being enveloped.  The resulting value of the
> encryption process
> >is then wrapped in an OCTET string for transporting."
>
> John Pawling said: I believe that this paragraph should be
> deleted because
> it is redundant to the first paragraph in section 6.3.
>
> There was one point in the second paragraph that I thought should be
> preserved.  I have merged the two paragraphs as follows:
>
>     The content-encryption key for the desired content-encryption
>     algorithm is randomly generated.  The input to the
> content-encryption
>     process is the "value" of the content being enveloped.  This input
>     data is padded as described below, then the padded data
> is encrypted
>     using the content-encryption key.  The encryption
> operation maps an
>     arbitrary string of octets (the data) to another string of octets
>     (the ciphertext) under control of a content-encryption key.  The
>     encrypted data is included in the envelopedData
> encryptedContentInfo
>     encryptedContent OCTET STRING.
>
> Note:  Nothing is marked as "[*** NEW ***]."  I consider this
> change to be
> completely editorial.

I don't like the text "This input data is padded as described below, ...".
However as this relates to my comment #28, I will think about this before
objecting.

>
> > > >37) Section 11.1: There MUST be exactly one instance of
> AttributeValue
> > > >present.  -- MUST NOT is not testable.
> > >
> > > It says: "A content-type attribute MUST have a single
> attribute value, even
> > > though the syntax is defined as a SET OF AttributeValue.
> There MUST NOT be
> > > zero or multiple instances of AttributeValue present."
> > >
> > > So, you agree with the first sentence.  I think the
> second sentence is a
> > > restatement of the first.  Does the second sentence help
> anyone understand?
> >
> >I don't believe that the second statement helps.  I did miss
> the fact that
> >it is a restatement of the first.
>
> Perhaps making it all one sentence will make it clear that
> there is only
> one idea being expressed.  I consider this an editorial
> change, and I did
> not insert "[*** NEW ***]."
>
> How about:
>
>     Even though the syntax is defined as a SET OF AttributeValue, a
>     content-type attribute MUST have a single attribute value; zero or
>     multiple instances of AttributeValue are not permitted.
>

I find this much clearer

> Russ

jim

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 11 Jul 2001 16:12:29 -0400

John:

>25) Section 6.2.1, para "rid":  Please change "support one at least of these
>alternatives." to  "support at least one of these alternatives."

Done.

>29) Section 6.3, para 2:  You want to preserve the following sentence: "The
>input to the content-encryption process is the "value" of the content being
>enveloped."  In my opinion, this sentence is not needed and is confusing.
>For example, when encrypting an ASN.1 encoded content, an implementer might
>interpret this statement to mean that the tag and length octets of the ASN.1
>encoded content should not be encrypted.  I still believe that the first
>paragraph is fine (as is included in draft-ietf-smime-rfc2630bis-01) and
>that the second paragraph should be deleted.

Here is the text that I have in the yet-to-be-published -02 draft.

6.3  Content-encryption Process

    The content-encryption key for the desired content-encryption
    algorithm is randomly generated.  The input to the content-encryption
    process is the "value" of the content being enveloped.  This input
    data is padded as described below, then the padded data is encrypted
    using the content-encryption key.  The encryption operation maps an
    arbitrary string of octets (the data) to another string of octets
    (the ciphertext) under control of a content-encryption key.  The
    encrypted data is included in the envelopedData encryptedContentInfo
    encryptedContent OCTET STRING.

    Some content-encryption algorithms assume the input length is a
    multiple of k octets, where k is greater than one.  For such
    algorithms, the input shall be padded at the trailing end with
    k-(lth mod k) octets all having value k-(lth mod k), where lth is
    the length of the input.  In other words, the input is padded at
    the trailing end with one of the following strings:

                      01 -- if lth mod k = k-1
                   02 02 -- if lth mod k = k-2
                       .
                       .
                       .
             k k ... k k -- if lth mod k = 0

    The padding can be removed unambiguously since all input is padded,
    including input values that are already a multiple of the block size,
    and no padding string is a suffix of another.  This padding method is
    well defined if and only if k is less than 256.

Are you happy with this text?  If not, I suspect your concerns are in the 
1st paragraph, not the 2nd one.

>36) countersignatures: Also, please change Section 5.4, para 2, as follows:
>
>OLD: "The content type attribute is not required when used as part of a
>countersignature unsigned attribute as defined in section 11.4."
>
>NEW: "The content-type attribute MUST NOT be used as part of a
>countersignature unsigned attribute as defined in section 11.4."

Done.

Russ