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

From: "Housley, Russ" <[email-masked]>
Date: Wed, 06 Jun 2001 16:36:07 -0400

Jim:

Thanks for spending so much time with the document.  You have performed a 
real service here.  I think that the bulk of your comments are handled 
here.  There are a few that need further dialogue.

>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"?

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

I have asked Jeff and Marcus for guidance.  So far, I have not received input.

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

Done.

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

Done.

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

I thought that the rewording removed the "must."  We agree that the MUST 
statement belongs in the discussion of signed attributes and authenticated 
attributes.  How about this:

    As a general design philosophy, each content type permits single pass
    processing using indefinite-length Basic Encoding Rules (BER)
    encoding.  Single-pass operation is especially helpful if content is
    large, stored on tapes, or is "piped" from another process.  Single-
    pass operation has one significant drawback: it is difficult to
    perform encode operations using the Distinguished Encoding Rules
    (DER) [X.509-88] encoding in a single pass since the lengths of the
    various components may not be known in advance.  However, signed
    attributes within the signed-data content type and authenticated
    attributes within the authenticated-data content type need to be
    transmitted in DER form to ensure that recipients can verify a
    content that contains one or more unrecognized attributes.  Signed
    attributes and authenticated attributes are the only CMS data types
    that require DER encoding.

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

Agree.  How about:

    The signer's certificate can be included in the SignedData
    certificates field.

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

How about:

    Implementations MAY fail to validate signatures that use a
    digest algorithm that 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.

How about:

    certificates is a collection of certificates.  It is intended that
    the set of certificates be sufficient to contain chains from a
    recognized "root" or "top-level certification authority" to all of
    the signers in the signerInfos field.  There may be more
    certificates than necessary, and there may be certificates
    sufficient to contain chains from two or more independent top-
    level certification authorities.  There may also be fewer
    certificates than necessary, if it is expected that recipients
    have an alternate means of obtaining necessary certificates (e.g.,
    from a previous set of certificates).  The signer's certificate
    MAY be included.  As discussed above, if version 2 attribute
    certificates are present, then the value of version MUST be 4.
    While the use of version 1 attribute certificates is discouraged,
    if version 1 attribute certificates are present and no version 2
    attribute certificates are present, then the value of version MUST
    be 3.

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

Agree.  Done.  I changed "should" to "MUST" in two places.

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

Ooops.  I changed "three" to "two".

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

How about:

    digestAlgorithm identifies the message digest algorithm, and any
    associated parameters, used by the signer.  The message digest is
    computed on either the content being signed or the content
    together with the signed attributes using the process described in
    section 5.4.  The message digest algorithm SHOULD be among those
    listed in the digestAlgorithms field of the associated SignerData.
    Implementations MAY fail to validate signatures that use a digest
    algorithm that is not included in the SignedData digestAlgorithms
    set.

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

Agree.  Done.

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

Agree.  Done.

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

I agree that the ASN.1 definition and this must statement are 
redundant.  They are not contradictory.  What do you not understand?  What 
change are you requesting?

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

Agree.  Done.

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

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

Agree.  Done.

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

It is pretty confusing.  How about:

       [*** NEW ***] version is the syntax version number.  The
       appropriate value depends on originatorInfo, RecipientInfo, and
       unprotectedAttrs.  The version MUST be assigned as follows:

          IF (originatorInfo is present) OR (unprotectedAttrs is present)
          THEN
             IF (any version 2 attribute certificates are present)
             THEN version is 3
             ELSE version is 2
          ELSE
             IF (any RecipientInfo structures are a version other than 0)
             THEN version is 2
             ELSE version is 0

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

Agree.  Done.

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

How about:

    certs is a collection of certificates.  certs may contain
    originator certificates associated with several different key
    management algorithms.  certs may also contain attribute
    certificates associated with the originator.  The certificates
    contained in certs are intended to be sufficient for all
    recipients to build certification paths from a recognized
    "root" or "top-level certification authority."  However, certs
    may contain more certificates than necessary, and there may be
    certificates sufficient to make certification paths from two or
    more independent top-level certification authorities.
    Alternatively, certs may contain fewer certificates than
    necessary, if it is expected that recipients have an alternate
    means of obtaining necessary certificates (e.g., from a
    previous set of certificates).

>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?

We use "SET OF" many places.  I do not think we want to add "SIZE (1..MAX)" 
to them all.  Therefore, I am not sure that there is any real value in 
adding it to this one.

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

Agree. Done.

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

Agree.  How about:

    The same content-encryption algorithm and content-encryption
    key are used for all recipients.

>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"

Agree.  Done.

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

I see no reason to do this.  Is there a constituency that needs it?

>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 ]]]]]

I did think about your comment, and I do not think so.  [[ I am 
anticipating an embarrassing reply. ]] This field is within the key 
transport recipient information, therefore any recipient public key that is 
used with this syntax (and is interoperable) must be a key transport key.

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

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

Agree.  Done.

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

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

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

I understand your point.  These words have not changed in a very long 
time.  Perhaps you would like to propose some better ones.

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

Good idea.  Done.

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

Okay.  Done.  I called it "HMAC-SHA-1."

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

Agree. Done.

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

Long story.  The short version is that v2 ACs are not backward compatible 
with v1 ACs.  If you really want to hear the nasty, dirty details, I 
suggest you talk to Hoyt or Sharron.  This little jewel is the reason that 
the PKIX AC Profile requires the use of v2 ACs.

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

Agree.  I changed "MAY" to "may" in three places.

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

Agree.  This is a place holder.  I think I will know when son-of-RFC2459 
finally makes it through the PKIX WG, IESG, and RFC Editor....

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

Elsewhere the document says: "The content-type attribute is not required 
when used as part of a countersignature unsigned attribute as defined in 
section 11.4."  This does not say MUST NOT to me.  It says MAY.  Eh?

>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?

>38) Section 11.2: See comment 37.

See response to comment 37. (I could not resist...)

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

Okay.  Done.

>40) Section 11.3: See comment 37.

See response to comment 37.

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

Agree.  Done.

>42) Section 11.4: See comment 37.

See response to 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.)"

I assume that this is a comment about section 11.4, there is no section 11.5.

See response to comment 36.  It seem to me that you are interpreting "need 
not" as "MUST NOT."  What have other implementors done?

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

I assume that this is a comment about section 11.4, there is no section 11.5.

Agree.  Done.

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

See response to comments 36 and 43.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 6 Jun 2001 15:28:19 -0700

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Wednesday, June 06, 2001 1:36 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Comments: draft-ietf-smime-rfc2630bis-00
>
>
> Jim:
>

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.

> I have asked Jeff and Marcus for guidance.  So far, I have

We will see what happens.

>     that require DER encoding.

This is fine.

>     The signer's certificate can be included in the SignedData

This is fine.

>     digest algorithm that is not included in this set.

I am more that happy with this this.  It was my perfered answer.

>     attribute certificates are present, then the value of version MUST

Looks fine.

>     algorithm that is not included in the SignedData digestAlgorithms

fine.

> change are you requesting?

I am requesting the removal of the MUST as there is no option. (Just to be
irritating, the field could be present but of zero length under the current
text.)

>     attrType.  The attrType MAY impose restrictions on the number of

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

>              IF (any RecipientInfo structures are a version

This is fine.

>     previous set of certificates).

Looks good.

> to them all.  Therefore, I am not sure that there is any real

This is the only one that I see where we have a requirement that the set
must not be empty and the element itself is not optional.  In most all of
the other locations either the element itself can be omitted or the SET can
consist of 0 items.

>     key are used for all recipients.

fine.

> I see no reason to do this.  Is there a constituency that needs it?

I was thinking of the PGP people, but don't have anything stronger.  I don't
think we need to do this.

> >if there is a MUST for it being in the certificate.
[ 
> Think about this
> transport recipient information, therefore any recipien
t
> public key that is

The comment was for me, and I missed it in the review of the message.  I
think I must have been wandering when I wrote this and I don't remember why.
Omit.

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

> would like to hear from more implementors before I make a change here.

John - please respond.

> but if padding is needed, this is the padding technique that

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.

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

> the PKIX AC Profile requires the use of v2 ACs.

I can buy that. (Also it does justify uping the version number for me.)

> section 11.4."  This does not say MUST NOT to me.  It says MAY.  Eh?

I agree that that is what it presently says.  In practice I don't believe
that any has ever encoding in a content-type and I would like to codify that
practice.

> restatement of the first.  Does the second sentence help

I don't believe that the second statement helps.  I did miss the fact that
it is a restatement of the first.

> not" as "MUST NOT."  What have other implementors done?

see comment above on 36.

> Russ

jim

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 28 Jun 2001 11:01:18 -0400

Jim:

Here are my responses.  I have not included the comments where my previous
reply resolved your concerns.

Where appropriate, I have addressed John Pawling's comments at the same
time.  I hope that this leads to quicker closure, not confusion is
subsequent replies to this message.

>phrase "the CMS" is quite common.  I count 5 that should be altered.

Okay.  I added "the" in the places that seems appropriate.

> > I have asked Jeff and Marcus for guidance.  So far, I have

This is may be a thorny issue, so I started a separate thread for it.

>irritating, the field could be present but of zero length under the current

John Pawling said: 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.

Okay, you guys have convinced me.  I dropped the first portion of the
sentence.  The text now says:

       signature is the result of digital signature generation, using the
       message digest and the signer's private key.  [*** NEW ***] The
       details of the signature depend on the signature algorithm
       employed.

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

>the other locations either the element itself can be omitted or the SET can

John Pawling said: I agree with Jim's recommendation.

Jim makes a good point.  I will add the "SIZE (1..MAX)" here.

> > >a)  do we want to change to text to allow for SKI's to be
> non-certificate based.
>[Snip]
>

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.

> > would like to hear from more implementors before I make a change here.

John Pawling said: 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.

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.

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

> > >29) Section 6.3, para 2:  I don't like the second sentence in this

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.

>that any has ever encoding in a content-type and I would like to codify that

John Pawling said: 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."

I changed the discussion of the content-type attribute in section 5.3 as
follows:

          A content-type attribute having as its value the content type
          of the EncapsulatedContentInfo value being signed.  Section
          11.1 defines the content-type attribute.  [*** NEW ***]
          However, the content-type attribute MUST NOT be used as part of
          a countersignature unsigned attribute as defined in section
          11.4.

I also changed section 11.4 to match:

    [*** NEW ***] Countersignature values have the same meaning as
    SignerInfo values for ordinary signatures, except that:

       1.  The signedAttributes field MUST NOT contain a content-type
       attribute; there is no content type for countersignatures.

       2.  The signedAttributes field MUST contain a message-digest
       attribute if it contains any other attributes.

       3.  The input to the message-digesting process is the contents
       octets of the DER encoding of the signatureValue field of the
       SignerInfo value with which the attribute is associated.

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

> > not" as "MUST NOT."  What have other implementors done?

John Pawling said:  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.

I composed the text in response to comment 36 before I read John's
proposal.  My text and John's text are almost identical (except for order),
so I assume that the text that I proposed above is acceptable.

Russ