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

From: "Jim Schaad" <[email-masked]>
Date: Wed, 6 Jun 2001 14:21:36 -0700

Russ,

Sorry about taking so long.  Here is my first set of comments:

1.  "The CMS ..." should be uniformly changed to "CMS ...".

2.  I have a sever problem with the following text "However, implementations
of the CMS MUST support the mandatory to implement algorithms specified in
[CMSALG], or its successor."  It is my believe that this statement should be
removed for the following reasons:

a)  This violates the letter and spirit of the IETF process rules for
pushing documents to standards.  In my opinion if this becomes a standard
then CMSALG must also be a standard.  Also if CMSALG is reset to draft, so
must this draft.  The words "MUST support" is extremely normative.

b)  If I create a toolkit or other system and publish that I am STD [CMS]
conformant.  It does not make sense that by updating the set of required
algorithms I loose conformance to that standard.  I was compliant, I loose
compliance through no action of mine.  This argues that a new standard
number should be applied.

c)  The reasoning behind not having a MUST for certificates is even more
strongly appliciable here.  While certificates and heirarchies can move
between different applications (thus making the arugment that application
spaces should mandate algorithms a somewhat odd argument), that is not the
case with CMS objects.  If S/MIME and CMS/SET were to specificy that
different content encryption algorithms be required, there is no
interactions between the spaces.  An S/MIME message would never be consumed
(successfully) by a CMS/SET application nor would one expect it to be used.

From this standpoint I think that not requiring a MUST on algorithms from
CMS makes sense.

3) Section 2, para 2:  Remove "if desired" from the last sentence.  That is
what MAY means.

4) Section 2, para 3: "within the authenticated-data content types require"
types should be singular.

5) Section 2, para 3: Revert to original language on DER encoding of signed
and authenticated attributes. The correct location for the MUST statement is
in the description of the attribute fields in the appropriate structures.

6) Section 5, para 8:  The MAY should be lower case.  This section is
descriptive in nature is not creating requirements on the implementor.

7) Section 5.1, digestAlgorithms:  One of the following statements should be
added to this paragraph:
a) Each digest algorithm used in a signture computation MUST be included in
this set, although unused algorithms may also be included.  OR
b) Complient implementations MUST verify signatures for which the digest
algorithm is not in this set. OR
c) Complient implementations MAY fail signature verification if the digest
algorithm is not included in this set.

8) Section 5.1, certificates:  The following items are missing from this
paragraph.  1) If version 2 attribute certificates are present the version
MUST be 4.  2) The MAY from section 5, para 8 if it is considered of
importance.  I think it can be omitted.

9) Section 5.2, para 7:  Change "the content type within ... should be
id-data" to "MUST be id-data"  and "content field ... MUST be omitted".

10) Section 5.3, para "sid":  What is the third alternative for specifying
the signer's public key?

11) Section 5.3, para "digestAlgorithm"  See comment 7 above.  Does the
should in the last sentence need to be SHOULD/MUST?

12) Section 5.3, para "signedAttributes":  Should be "signedAttrs".

13) Section 5.3, para "signedAttributes":  "Each SignedAttribute in the SET
MUST be DER encoded."

14) Section 5.3, para "signature":  I don't understand the MUST in this
paragraph.  The field is not optional how can it be omitted?  The MUST is
redundant.

15) Section 5.3, para "unsignedAttributes": should be "unsignedAttrs".

16) Section 5.3, para "attrValues":  Append the following sentence.
"attrType may impose additional restrictions on the number of items in the
set."

17) Section 5.6, para 1: Change "MAY" to "may".

18) Section 6.1, para "version":  What is the correct value if v2 attribute
cert and unprotected attributes are present?  Maybe should change this to an
if - then - else type of writing.

19) Section 6.1, para "originatorInfo":  Change MAY to may in last sentence.
No requirement is stated here.

20) Section 6.1, para "certs": ditto above for some.  What is the "optional"
feature being discussed on the MAY.

21) Section 6.1, para "recipientInfos":  Should change the ASN to
"RecipientInfos ::= SET SIZE (1..MAX) OF RecipientInfo" to reflect the MUST
in the text?

22) Section 6.1, para "encryptedContentInfo":  Remove the [*** NEW ***]
text.  The field is not optional.

23) Section 6.1, para "contentEncryptionAlgorithm":  Please explain the
MUST.  How could you NOT use the same algorithm for each recipient?

24) Section 6.1, para "encryptedContent":  Please explain how the MUST in
this paragraph would be tested.  I think this is a "must" not "MUST"

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.
b)  do we need a stronger definition of what a key transport public key is
if there is a MUST for it being in the certificate.  [[[[ Think about this
comment ]]]]]
c)  do we need to support both for specifying the certificate or just for
locating a certificate? (i.e. encode vs decode)

26) Section 6.2.2, para 1:  "...one or more recipients that use..."

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.)

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.

29) Section 6.3, para 2:  I don't like the section 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.

30) Section 9.1:  Do we want to change the name of
unauthencticatedAttributes to unauthencticatedAttrs to be consistant with
the naming in signed and encrypted data?  (ditto with
autenticatedAttributes.)

31) Section 10.1.5: Should we change HMAC to HMAC-SHA1 as HMAC by itself is
not a MAC algorithm?

32) Section 10.2.1: Change MAY to may - not protocol requirement here.

33) Section 10.2.2: Why define another tag for v2 attribute certificates.
We have never bothered with this for v1/v2/v3 certificates.

34) Section 10.2.3: make MAY may, no protocol requirement imposed by CMS.

35) Section 11: Update RFC 2459 text reference to "Son of 2459".

36) Section 11.1: Content-type MUST be omitted when building counter
signatures.

37) Section 11.1: There MUST be exactly one instance of AttributeValue
present.  -- MUST NOT is not testable.

38) Section 11.2: See comment 37.

39) Section 11.3: I think we should loosen up the locations allows for
signing-time.  I would like to see it allowed as an autenticated attribute.

40) Section 11.3: See comment 37.

41) Section 11.4: should be "MUST NOT" not "MUST not" in the description of
generalizedTime.

42) Section 11.4: See comment 37.

43) Section 11.5: 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.)"

44) Section 11.5, UnsignedAttribute syntax: I disagree with the MAY here.  I
believe this should be lower case.  If there is a procotol statement it
needs to be that implementations MUST be able to handle more than one
counter signature attribute.

OTHER:
1) should countersign say MUST omit content type?

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 28 Jun 2001 09:13:17 -0400

Dear S/MIME WG:

A few weeks ago, Jim Schaad submitted a simple comment on 

> From this standpoint I think that not requiring a MUST on algorithms from

I have discussed this issue with both of the Security Area Directors.  Only 
one thing is clear: we cannot have a MUST statement that references 
"[CMSALG], or its successor."

If we were to achieve Full Standard status with the specification that we 
are working on, then changing the mandatory to implement algorithm would 
reset the status of the updated protocol to Proposed Standard.  I expect 
such a change at some point, probably to change the mandatory cipher from 
Triple-DES CBC to AES CBC.

There are other protocols besides S/MIME that are using CMS.  If CMS has 
mandatory to implement algorithms, then many of the interoperability issues 
are handled by a simple reference.  On the other hand, if CMS does not 
include any mandatory to implement algorithms, then each reference must 
specify them.

As many of you know, I am arguing for a common set of cryptographic 
algorithms throughout the IETF Security Area.  Having each CMS referee 
specify their own set of algorithms does not support this objective.

What do others think?

Russ

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 28 Jun 2001 14:43:58 -0700

At 9:13 AM -0400 6/28/01, Housley, Russ wrote:
>algorithms throughout the IETF Security Area.  Having each CMS 
>referee specify their own set of algorithms does not support this 
>objective.
>
>What do others think?

Russ is right on a technical front: the IETF should use a common set. 
It is now looking better that this might happen, given that the TLS 
folks are going to use RSA with OEAP for AES ciphers.

On a political front, this is going to be a long battle. The IETF 
security area takes forever to act on things that they have agreed 
to; for instance, IPsec still mandates DES (not TripleDES) years 
after our self-congratulatory pronouncements about changing. There is 
very little cross-pollination in the security area, as shown by the 
TLS debate.

It is worth a shot, but don't expect success.

--Paul Hoffman, Director
--Internet Mail Consortium