Tim Dean wrote:
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
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 pur
Note: The last line above was snipped by my mailer.
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.
It strikes me that a set of basic purpose codes could be provided
as a named bit list instead of by using object identifiers as the
ASN.1 above describes. For example,
BasicPurposeCodes ::= BIT STRING {
messageOriginator (0),
messageForwarder (1),
contentOriginator (2),
hTTPOriginator (3),
contentReviewer (4),
securityLabe (5),
timeStamp (6)
}
The actual text associated with each code could be defined by this
standard as ordinary text. These meanings could be translated into
whatever national languages needed by an implementation for display
purposes. The use of the BIT STRING would allow a set of basic
purposes to be transmitted more efficiently and processed more
easily than using a set of sigPurposeId object identifiers.
The component of SignaturePurposeCode, purposeQualifier, is ASN.1
type PrintableString, which does not support national languages,
and does not even support all of the visible ASCII characters. I
would think type VisibleString (all ASCII with no control chars.)
more useful, but would prefer either...
PurposeQualifier ::= CHOICE {
visASCII VisibleString (SIZE (1..maxPurposeQualifierSize)),
unicode BMPString (SIZE (1..maxPurposeQualifierSize))
}
if valid ASN.1:1994 were supported, and
SignaturePurposeCode ::= UTF8String
(SIZE(1..maxPurposeQualifierSize))
if ASN.1:1998 were used. This would allow alternative definitions
for these types:
SignaturePurpose ::= SEQUENCE {
basics BasicPurposeCodes,
others SigPurposeCodes OPTIONAL
}
SigPurposeCodes ::= SET OF SignaturePurposeCode
SignaturePurposeCode ::= SEQUENCE {
sigPurposeId OBJECT IDENTIFIER,
purposeQualifier PurposeQualifier
}
The above definitions support national languages, and allow
efficient coding when only basic purpose codes are used. The
use of additional application-specific purpose codes is also
supported. Note, however, that this scheme doe not provide a
mechanism for specifying augmenting text with the basic purpose
codes, which may be viewed as either a bonus or a negative.
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.
Phil
--
Phillip H. Griffin Griffin Consulting
asn1(_at_)mindspring(_dot_)com ASN.1-SET-Java-Security
919.828.7114 1625 Glenwood Avenue
919.832.7008 [mail] Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------