Tim Dean wrote:
Phil,
different set of purpose codes. The signature pur
Note: The last line above was snipped by my mailer.
The last bit of this paragraph said "The signature purpose attribute applies
only to the signature in SignerInfo which contains it. It does not apply to
any other signature."
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.
Your suggestion about making the basic purpose codes a bit string
and application specific ones OIDs looks sensible to me. However,
if I've understood your suggested ASN.1 correctly, the purpose
qualifier can now only be added to app-specific codes. Is that correct?
Yes.
If so, the original intent was also to allow qualifying text for
basic codes as well. As an example, for the content review code,
someone may wish to further qualify why he/she/it has signed content
in human-readable form: "I'm virus scanner ABC running in domain XYZ.
I've checked and reviewed this content before it got to you.". Do you
have a suggestion of how to tweak the ASN.1 to support this?
I noted this difference in capability in my post, and I believe that
it could be viewed as either a bonus or a negative in the design. It
is possible that the qualifier text might contradict text assumed for
the basic purpose codes, and lead to ambiguity. If qualifier text is
not allowed for the basic purpose codes, I thought that they might
be more useful for applications, and easier to implement.
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'.
I'm also told SEQUENCE OF generates slightly more efficient encoding
than SET OF. If this is the case then this would make sig purpose more
efficient too.
Under DER, SET OF components require sorting, but SEQUENCE OF does not.
I would prefer always using SEQUENCE OF, but SET OF is commonly used in
SMIME, since it relies on an old version (1.5) of PKCS #7, so I assumed
that sorting was not an important consideration. It *is* important in
the modified SignaturePurpose type component 'basicQuals' shown above.
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:
The consensus at the last meeting was to use the 1988 ASN.1 definition
- see the minutes for the discussion and conclusions. Is it possible to
re-express the above in 1988 ASN.1?
My mistake. Neither BMPString(1994-8) nor UTF8String(1998) should be
used in standards defined to adhere to ASN.1:1988, though the 'rules'
for what is and what is not valid ASN.1 escape me. I confess that I
have no experience with mixing ASN.1 versions. Sorry for the flux.
Still, you may wish to consider VisibleString over PrintableString,
though neither of these types supports national languages.
Regards,
Tim
----------
From: Phillip H. Griffin [SMTP:asn1(_at_)mindspring(_dot_)com]
Sent: Wednesday, January 14, 1998 7:06 PM
To: Tim Dean
Cc: 'ietf-smime(_at_)imc(_dot_)org'
Subject: Re: Proposal: Re: 'Signature Purpose' attribute?
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
------------------------------------------------------------