After discussion with one or two people I have put together some suggested text
for the signature purpose attribute. This is now offered to the list for
comment. The intent would be to add this text as part of section 10 of CMS,
providing there is WG consensus.
Comments welcome!
Tim Dean
------------------- cut here ---------------------------------
10.x Signature Purpose
The signature purpose attribute specifies the purpose for which the signature
was created. It is intended to be used in circumstances where there may
otherwise be ambiguity in the intention of the signer. For example, it assists
in preventing signed content created in one application (e.g. a signed file or
HTTP transaction) being unintentionally or maliciously mis-used by another
(e.g. to authenticate a message originator). It can also be used to protect an
entity wishing to sign and forward a message from being wrongly implicated as
being the message originator.
The signature purpose attribute is identified by the following object
identifier:
id-sigPurpose OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) xxx }
Signature purpose attribute values have ASN.1 type SignaturePurpose:
SignaturePurpose ::= SET OF SignaturePurposeCode
SignaturePurposeCode ::= SEQUENCE {
sigPurposeId OBJECT IDENTIFIER,
purposeQualifier PrintableString (SIZE
(1..maxPurposeQualifierSize))}
maxPurposeQualifierSize INTEGER ::= 1024
The signature purpose attribute MUST be an authenticated attribute; it MUST NOT
be included as part of authenticated attributes. When signing content an
S/MIME application SHOULD include at least one purpose code, taken either from
the list below or an application-specific purpose code. An S/MIME application
may include more than one purpose code. There can be multiple SignerInfos
associated with a SignedData object, and each one may include a different set
of purpose codes. The signature purpose attribute applies only to the
signature in SignerInfo which contains it. It does not apply to any other
signature.
A number of basic purpose codes are defined here for use by S/MIME
applications. Further purpose codes may be defined on an application-specific
basis. An implementation may choose to populate the purposeQualifier field with
text which further describes the purpose.
The following basic S/MIME purpose codes are defined:
* Message originator - the signer originated the message together with the
content of the message. Signature purpose code id-SigPurposeMessageOriginator
is used for this purpose.
* Message forwarder - the signer forwarded the message but did not originate
it. Signature purpose code id-SigPurposeMessageForwarder is used for this
purpose. One use of this purpose code is by a Mail List Agent (MLA) expanding
a message to a distribution list.
* Content originator - the signer originated the signed content, but does not
intend sending it out as a mail message. Signature purpose code
id-SigPurposeContentOriginator is used for this purpose. A typical use of this
purpose code is to add an S/MIME signature to local files and documents inside
a system.
* HTTP originator - the signer originated the HTTP content. Signature purpose
code id-SigPurposeHTTPOriginator is used for this purpose.
* Content review and approval - the signer reviewed and approved the content
but did not originate it. Signature purpose code id-SigPurposeContentReviewer
is used for this purpose. A possible use of this purpose code is by a 'virus
scanner' checking for malicious code in content. Another use is by 'release
authorities' used in some situations to release messages through a firewall.
In both cases, further qualifying text could be added in the purposeQualifier
field.
* Security label - the signer added the signed security label but did not
originate the content. Signature purpose code id-SigPurposeSecurityLabel is
used for this purpose.
* Timestamp - the signer added a signed timestamp but did not originate the
content. Signature purpose code id-SigPurposeTimestamp is used for this purpose.
'Message Originator', 'Content Originator', and 'HTTP originator', may be used
in a SignerInfo on content but SHOULD NOT be used in a countersignature. All
the other codes listed may be used in either a SignerInfo on content or in a
countersignature. An implementation may choose to compare the signature
purpose field with fields in the certificate before deciding whether the
signature is valid.