Blake Ramsdell wrote:
snip
If you have specific changes that surround things other than
capitalization of OIDs (the ChallengePassword CHOICE is a good one) then
snip
X.208 does not require identifiers for the two choice alternatives
provided in the following definition, neither does it prohibit
their use.
-- 5.2.1 Challenge Password
ChallengePassword ::= CHOICE {
PrintableString, T61String }
So this could be rewritten as something like...
ChallengePassword ::= CHOICE {
printableString PrintableString,
t61String T61String
}
and a little bit of ambiguity would be eliminated from the
definition. This would only be of use to implementors that
wished to use automatic tools and the ASN.1 value notation
to generate challenge password values, perhaps to use in
their application or for test purposes.
Some tools support the automatic generation of encodings
of such values described using the value notation. Not of
any use at all for hand coders, or folks that still use
1980s-based tools. And in this particular case, where the
types are quite simple, being able to generate encodings
using value notation has little advantage, since it is
fairly easy to do by hand.
But when such types are embedded in more complex structures
the advantages of using the value notation can be quite
dramatic. For example, to generate an encoding of a complex
message like an unsigned certificate body, I need only write
something like...
myCert UnsignedCertificate ::= {
version 2,
serialNumber 1,
signature {
algorithm { 2 23 42 9 11 4 1 10 }, -- ECDSA 131 --
parameters NULL
},
issuer rdnSequence : {
{{ type { joint-iso-itu-t(2) ds(5) 4 3 }, -- commonName --
value printableString : "Phil Griffin" }},
{{ type { joint-iso-itu-t(2) ds(5) 4 6 }, -- countryName --
value printableString : "US" }},
{{ type { joint-iso-itu-t(2) ds(5) 4 10 }, -- org.Name --
value bmpString : "Self Certification Authority" }},
{{ type { joint-iso-itu-t(2) ds(5) 4 11 }, -- org.UnitName --
value printableString : "Root Certificate" }}
},
validity { notBefore utcTime : "970808070000Z",
notAfter utcTime : "990807070000Z"
},
subject rdnSequence : {
{{ type { joint-iso-itu-t(2) ds(5) 4 3 }, -- commonName
--
value printableString : "Phil Griffin" }},
{{ type { joint-iso-itu-t(2) ds(5) 4 6 }, -- countryName --
value printableString : "CA" }},
{{ type { joint-iso-itu-t(2) ds(5) 4 10 }, -- org.Name --
value bmpString : "Self Certification Authority" }},
{{ type { joint-iso-itu-t(2) ds(5) 4 11 }, -- org.UnitName --
value printableString : "Root Certificate" }}
},
subjectPublicKeyInfo {
algorithm {
algorithm { 2 23 42 9 11 4 1 10 }, -- ECDSA 131 --
parameters NULL
},
subjectPublicKey '30480241 ...and so on... C58D4FB0011A761C'H
},
extensions {
{ extnId { 2 5 29 5 }, -- privateKeyUsagePeriod (pkup) --
extnValue
'3022800F31393937313133303037303030305A810F31393938313133303037303030305A'H
},
{ extnId { 2 5 29 19 }, -- basicConstraints (isCA) --
critical TRUE,
extnValue '30030101FF'H
},
{ extnId { 2 5 29 15 }, -- keyUsage --
critical TRUE,
extnValue '03020182'H -- digitalSignature , cRLSign --
},
{ extnId { 2 5 29 17 }, -- subjectAltName --
extnValue
'301882165375626A65637420416C7465726E617465204E616D65'H
},-- Encoded GeneralNames, dNSName, "Subject Alternate Name" --
{ extnId { 2 5 29 18 }, -- issuerAltName --
extnValue '3017821549737375657220416C7465726E617465204E616D65'H
} -- Encoded GeneralNames, dNSName, "Issuer Alternate Name" --
}
}
and throw it in a tool, which will generate a C++ program to test
the notation by encoding and decoding the message, and displaying
the encoded results. And as shown above, the value notaion is not
bad for demonstrating the structure of complex messages.
But back to ChallengePassword. I believe that better choices can
be made for the alternatives presented here. PrintableString is
not such a good choice for users, since it does not allow them to
select characters from the full ASCII set that they see on their
keyboards. Since users are likely to attempt to select characters
that are not supported by this type, and since hand coders would
seem not so likely to implement ASN.1 permitted alphabet constraints,
I would argue that type VisibleString, which contains all of the
ASCII set minus the control characters, to be a better choice. I
believe that using VisibleString here might improve the chances of
applications, at least in the US, successfully interoperating.
Type T61String is from way back, the 80s I believe, and is another
name for type TeletexString, a restricted character string type. It
is/was popular in Europe, and I suppose has use for anyone that still
uses such a device. Its characters come from ISO/IEC 10646-1, but
contains the DELETE character among other goodies, may cause some
implementors problems, and does not provide a very usefull level of
national language support.
The ASN.1:1994 type BMPString is also based on ISO/IEC 10646-1, but
is mapped to the same characters described as Unicode. It supports
most if not all of the worlds written languages. A new type defined
in ASN.1:1998, UTF8String, provides all of the capabilities of type
BMPString and more. Unlike BMPString, which contains only double-
byte characters, UTF8String contains variable-width characters, and
I believe is favored by IESG. The first 'n' characters of the
UTF8String are the same as VisibleString, the visible ASCII set,
and are encoded more efficiently than BMPString, as single octets.
UTF8String would be a best choice for national language support,
and if you don't mind violating the ASN.1 standards by mixing
versions of ASN.1 together (kludges) that will break some folks
tools, I would prefer seeing UTF8String used over BMPString. Type
UTFString has its own distinct UNIVERSAL tag, so no further tagging
is required on the choice alternatives in the following
ChallengePassword ::= CHOICE {
printableString PrintableString,
t61String T61String,
visibleString VisibleString,
utf8String UTF8String
}
which might be desirable for backwards compatibility with previous
versions of ChallengePassword.
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
------------------------------------------------------------