Paul,
The following which I posted a few weeks ago shows some pros and cons
of the various approaches.
I am not sure what you mean by:
On a related issue: why do people who support the second format want
"[0]"? This is unneeded since there's no chance the item will get
confused with the PrintableString.
What alternative would you suggest? It is the key to forward
compatibility.
--------------------------------------------------------------------------
Bancroft Scott Toll Free :1-888-OSS-ASN1
Open Systems Solutions, Inc. International:1-609-987-9073
baos(_at_)oss(_dot_)com Tech Support
:1-732-249-5107
http://www.oss.com Fax :1-732-249-4636
---------- Forwarded message ----------
Date: Thu, 19 Feb 1998 00:25:19 -0500 (EST)
From: Bancroft Scott <baos(_at_)oss(_dot_)com>
To: "Jim Schaad (Exchange)" <jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com>
Cc: 'Paul Hoffman / IMC' <phoffman(_at_)imc(_dot_)org>,
ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comment on ESS and Privacy Marks
On Wed, 18 Feb 1998, Jim Schaad (Exchange) wrote:
At this point I am feeling really over my head on the question of UTF-8
vs OCTECT string, I don't have enough knowledge to put in useful input
on that issue. My general impression however is that I would perfer to
have the type explicit in this case rather than implicit.
Independent of that issue however, I think we should consider doing
either an implicit [0] or explicit [0] tag on the utf8String field.
Thus we would use
ESEPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String EXPLICIT [0] OCTET STRING
}
I can not think of a single case where an explicit tag is useful on
type OCTET STRING, for the contents is always opaque and is never
affected by tagging, whether IMPLICIT or EXPLICIT. Given this, the
only purpose that explicit tagging on this type serves is to increase
code size, message size and transmission time.
If we are hell-bent on using OCTET STRING to carry UTF8String
characters then I strongly recommend that you use an implicitly
tagged OCTET STRING. That is:
ESEPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String [0] IMPLICIT OCTET STRING -- MUST contain UTF-8-encoded
characters
}
The benefits of doing this are:
a) People who use tools that *do not* support UTF8String can accomplish
the same thing as they can if the type is tagged EXPLICIT, except that
there is no double tagging. For those not familiar with the details, "[0]
EXPLICIT OCTET STRING" results in a double-tagged encoding of:
[0] length1 [UNIVERSAL 4] length2 UTF8String-value
whereas "[0] IMPLICIT OCTET STRING" results in an encoding of:
[0] length UTF8String-value
b) People who use tools that *do* support UTF8String can leave the
definition as [0] IMPLICIT OCTET STRING if they wish, or they can change
the definition to "[0] IMPLICIT UTF8String" and end up with exactly the
same encoding as with no change. The benefit to doing is that they can
then rely on the tool they are using to automatically check the validity
of the UTF8String value (especially during development) if they wish.
c) Implicit tagging of OCTET STRING is most efficient all around and
does not impact anyone adversely.
d) If in a future version of S/MIME you choose to use valid ASN.1
consisting solely of the current ASN.1 version, you will be able
to change the "[0] IMPLICIT OCTET STRING" to "[0] IMPLICIT UTF8String"
without affecting the bits on the wire (i.e., the resulting encoding),
whereas "[0] EXPLICIT OCTET STRING" cannot be changed to use UTF8String
under any circumstance without introducing interoperability problems.
e) "[0] IMPLICIT OCTET STRING is absolutely no pain to folks who wish to
use X.208-specific toolkits, for it is simply an implicitly tagged octet
string that they all support.
My personal preference is to define:
ESEPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String [0] IMPLICIT UTF8String (SIZE (1..ub-privacy-mark-length))
}
One benefit is that you are able to clearly express the type and properly
constrain it in size (something you can't do with OCTET STRING that
carries a UTF8String value, other than by a comment - see below.) Another
benefit is that if someone is using a tool that does not support
UTF8String they can simply change it to "[0] OCTET STRING" and get the
same encoding. The down side to this is that it is invalid ASN.1 since
the S/MIME module mixes use of UTF8String with ANY, but this violation
is already occuring since BMPString is being used, so matters are not
being made any worse.
It would also be instructive to look at the issue of the size of the
utf8String field. It was limited to a specific length for the
PrintableString version. Should the utf8String version also be of
limited length?
Yes, a length would be ideal, for it tells implementors the max number of
characters they need to support. Note though that with OCTET STRING
there is no practical way to indicate the maximum number of characters
that is to be supported, only the maximum number of bytes used to encode
the character string value, for a size constraint on OCTET STRING
is a byte count, while a size constraint on UTF8String is a count of
the number of characters.
--------------------------------------------------------------------------
Bancroft Scott Toll Free :1-888-OSS-ASN1
Open Systems Solutions, Inc. International:1-609-987-9073
baos(_at_)oss(_dot_)com Tech Support
:1-732-249-5107
http://www.oss.com Fax :1-732-249-4636