Apologies to all for the fact that I still haven't managed to figure out
how to get my E-mail editor to line-wrap properly... (I've looked all
through the options, and there is seemingly no way of setting line
lengths - despite it being supposedly modern software.)
Here's a re-send of a message I sent earlier, this time using a
different editor. Hopefully this should fix it...
Tim
----------------------------
Phil Griffin [asn1(_at_)mindspring(_dot_)com] said:
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? 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?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.
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?
Regards,
Tim