Dave,
I really like your proposed generalisations of the original text - it hangs
together much better like that.
One option would be just add this new text to CMS 'as is', and allow people to
implement it if they so
choose, along with the other authenticated attributes. Or it might be better
in the interests of
interoperability to make it a 'SHALL' implement and support in protocol.
I personally much prefer the latter option, for a variety of reasons.
Thoughts?
Tim
----------
From: David P. Kemp [SMTP:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil]
Sent: Wednesday, March 18, 1998 10:15 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: 'Signature Purpose' attribute?
Tim,
I agree that designating the purpose of a signature is a useful
capability to include in CMS. Your original proposal is included
below, and Phil Griffin suggested an alternative syntax which used a
BIT STRING for basic purpose codes. I have some comments on your
proposal, and have a third syntax suggestion to throw into the pot.
It seems to me that the example purposes you listed are almost but not
quite general enough. Phil's syntax made a distinction between basic
and extended purpose codes, thereby accentuating concerns with the
specific purposes included in the basic set.
I propose that a signature have a single basic purpose selected from
a small list of mutually-exclusive options. In addition, a signature
could have zero or more qualifiers in addition to (not instead of)
the basic purpose. Qualifiers could have an OID, a string description,
or both:
SignaturePurpose ::= SEQUENCE {
basicPurpose BasicPurpose,
qualifiers SEQUENCE SIZE(1..MAX) OF Qualifier OPTIONAL }
BasicPurpose ::= ENUMERATED {
integrityOnly (0),
contentForwarder (1),
contentReviewer (2),
contentOriginator (3) }
Qualifier ::= SEQUENCE {
purposeCode OBJECT IDENTIFIER OPTIONAL,
description [0] IMPLICIT OCTET STRING (SIZE(1..maxDescSize))
OPTIONAL -- Must contain UTF-8 string }
The basic purposes are:
* integrityOnly - the signer does not intend the signature to be used
for any form of non-repudiation; it is intended only to provide
data integrity. This is equivalent to Tim's Content Originator
purpose used to sign files on a local disk, but not distributed to
anyone else.
* contentForwarder - the signer did not either originate or examine
the content; the signature is intended to provide data integrity and
data origin authentication. Equivalent to Tim's Message Forwarder,
used by a Mail List Agent.
* contentReviewer - the signer did not originate the content, but is
claiming to provide some value-added service to it. Provides
integrity, authentication, and non-repudiation of the claimed
value-added purpose, but not non-repudiation of the content.
Examples: virus scanning, release approval, timestamping, or
adding a security label.
* contentOriginator - the signer claims authorship. Equivalent to
Tim's Message Originator and HTML Originator (I don't know why there
is a distinction between a plain text message and an HTML message,
but if the distinction is important, a qualifier could be used.)
Note that anyone can add a signature claiming ownership/authorship of a
document; the primary reason for signaturePurpose is therefore to
enable the signer to disclaim some responsibility which is otherwise
authorized by the signer's certificate. Therefore the contentOriginator
purpose is really a "null-disclaimer".
I expect that extended purpose codes (OIDs), if needed at all, would
only be used in conjunction with the contentReviewer basic purpose.
Timestamp and security label purposes can be inferred from the presence
of the respective signed attributes; virus scanning and release approval
are categories that probably require privileges to be set in the signer's
certificate, rather than being set or unset in each signature. I would
like to see solid justification before defining any S/MIME extended
signature purpose OIDs. The syntax accommodates the use of private OIDs
for community-specific purposes; that should be sufficient to gain the
operational experience needed before recommending standardized purpose
codes.
Note that the Qualifier description field is a UTF8 string; it's
syntax should be consistent with whatever is used for UTF8 elsewhere
in S/MIME.
Comments welcome,
Dave Kemp
-------------------------------------------------------------------------
From: "Phillip H. Griffin" <asn1(_at_)mindspring(_dot_)com>
It seems to me that having a set of basic purpose codes as static
definitions might make them more useful for applications, and easier
to implement. The capability to provide application-specific OIDs with
accompanying qualifier text is still provided in the design.
Still, to have it both ways, my proposed type could be changed to:
SignaturePurpose ::= SEQUENCE {
basics BasicPurposeCodes,
basicQuals SEQUENCE OF VisibleString OPTIONAL,
others SigPurposeCodes OPTIONAL
}
The SEQUENCE OF would not be sorted under DER, so the order
specified by the sender would be maintained. One string per
bit flag could optionally be included in the message, with
the order assumed mapped to the high bits in 'basics'.
-------------------------------------------------------------------------
From: Tim Dean <t(_dot_)dean(_at_)eris(_dot_)dera(_dot_)gov(_dot_)uk>
Date: Tue, 13 Jan 1998 10:36:39 -0000
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.