Subject: CMS attributes question

From: Julien Stern <[email-masked]>
Date: Wed, 18 Mar 2009 18:40:22 +0100

Hi list,

We have a question related to CMS that was raised during an ETSI session 
around the CAdES standard:

we were wondering whether the behavior of an implementation encountering 
an unknown attribute was defined. One line of thinking is that an 
_unsigned_ attribute can be ignored by an implementation, but that the 
signature validation should fail if an unknown _signed_ attribute is 
encountered.

Is this behavior somehow defined in CMS (I did not see it, but I might 
have missed it)?
Otherwise, what do you think? What does your implementation do when it 
encounters an unknown signed attribute?

Regards,

--
Julien

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Mar 2009 14:56:49 -0400

Unrecognized attributes are ignored.  RFC 3852 requires support for 
the content type and message digest attributes, but all others can be 
ignored if they are not recognized.

Russ

At 01:40 PM 3/18/2009, Julien Stern wrote:

>Hi list,
>
>We have a question related to CMS that was raised during an ETSI 
>session around the CAdES standard:
>
>we were wondering whether the behavior of an implementation 
>encountering an unknown attribute was defined. One line of thinking 
>is that an _unsigned_ attribute can be ignored by an implementation, 
>but that the signature validation should fail if an unknown _signed_ 
>attribute is encountered.
>
>Is this behavior somehow defined in CMS (I did not see it, but I 
>might have missed it)?
>Otherwise, what do you think? What does your implementation do when 
>it encounters an unknown signed attribute?
>
>Regards,
>
>--
>Julien
>

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 19 Mar 2009 18:44:35 +1300

Russ Housley <[email-masked]> writes:

>Unrecognized attributes are ignored.  RFC 3852 requires support for the
>content type and message digest attributes, but all others can be ignored if
>they are not recognized.

In addition handling of content-type seems to be pretty hit-and-miss, I've
seen messages created by different implementations that have no content-type
and nothing seems to mind (well, my code did which is why I noticed it :-) but
there don't seem to have been sufficient problems caused by other
implementations complaining that the developers felt the need to fix things.

Peter.

---

From: Julien Stern <[email-masked]>
Date: Thu, 19 Mar 2009 09:31:26 +0100

Russ,

thank you for your answer.

Isn't it dangerous to ignore a _signed_ attribute ?
In the case of an attribute such as ESSCertID or ESSCertIDV2 (RFC 2634 
ou RFC 5035), an implementation ignoring the attribute can give 
inconsistent results versus a implementation not ignoring the result 
(e.g. the signature is valid vs the signature has been forged).

Also, when you are writing the these attributes are ignored, do you mean 
that they MUST be ignored or that they MAY be ignored? E.g. if my 
implementation fails upon receiving a signature with an unknown signed 
attribute, would you consider this non-standard? Or is this behavior up 
to the implementor?

Regards,

--
Julien

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 19 Mar 2009 07:56:39 -0700

>Isn't it dangerous to ignore a _signed_ attribute ?

No. The fact that the signer wanted the data to be protected in transport doesn't mean that it is inherently important to the recipient. The decision to sign an attribute is usually made by the software developer (and could come down to "well, why not?"), not the sender.

>Also, when you are writing the these attributes are ignored, do you mean that they MUST be ignored or that they MAY be ignored? E.g. if my implementation fails upon receiving a signature with an unknown signed attribute, would you consider this non-standard? Or is this behavior up to the implementor?

The latter. Remember, we can't say what it really means to "understand" an attribute.

---

From: Julien Stern <[email-masked]>
Date: Thu, 19 Mar 2009 16:29:01 +0100

> No. The fact that the signer wanted the data to be protected in transport doesn't mean that it is inherently important to the recipient. The decision to sign an attribute is usually made by the sof…
Paul,

The problem is that for some specific attributes (such as some in RFC 
2634, RFC 5035 or CAdES) begin capable of processing the attribute or 
not will influence the actual result of signature validation.
> The latter. Remember, we can't say what it really means to "understand" an attribute.
OK. Thanks. One (hopefully) last question:
if in CAdES (which extends CMS as you surely know), we mandated 
signature validation to stop if a signed attribute is not supported by 
the verifying implementation, would you consider this inconsistent with 
CMS or not?

Best regards,

--
Julien

---

From: Russ Housley <[email-masked]>
Date: Thu, 19 Mar 2009 16:02:07 -0400

Some specification that make use of CMS mandate support for 
additional attributes.  These attributes are vital in the application 
environment.  I know that S/MIME requires support for some, and 
recommends support for a few others.  I think that time stamps are in 
a similar situation.

Russ

At 04:31 AM 3/19/2009, Julien Stern wrote:
>In the case of an attribute such as ESSCertID or ESSCertIDV2 (RFC 
>2634 ou RFC 5035), an implementation ignoring the attribute can give 
>Also, when you are writing the these attributes are ignored, do you 
>mean that they MUST be ignored or that they MAY be ignored? E.g. if 
>my implementation fails upon receiving a signature with an unknown 
>signed attribute, would you consider this non-standard? Or is this 
>behavior up to the implementor?
>
>Regards,
>
>--
>Julien
>
>
>Russ Housley a écrit :
>>
>>the content type and message digest attributes, but all others can 
>>be ignored if they are not recognized.
>>
>>Russ
>>
>>>encountering an unknown attribute was defined. One line of 
>>>thinking is that an _unsigned_ attribute can be ignored by an 
>>>implementation, but that the signature validation should fail if 
>>>an unknown _signed_ attribute is encountered.
>>>
>>>Otherwise, what do you think? What does your implementation do 
>>>when it encounters an unknown signed attribute?
>>>
>>>Regards,
>>>
>>>--
>>>Julien