ietf-smime
[Top] [All Lists]

Re: Proposal: Re: 'Signature Purpose' attribute?

1998-01-14 12:00:31
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
------------------------------------------------------------