(1) Internet Mail Address
InternetMailAddress ::= PrintableString
X.208 table 5 does not have the "@" character as part of PrintableString.
Has this been changed in the new ASN.1 definition, or would this be requiring
the "(a)" encoding defined in RFC 1327? Perhaps the IA5 character set has
the at symbol.
(2) Printable Subject Identifier
Its purpose is to provide a string suitable for display in user interfaces,
e.g., when advising a signature-verifying user of the identity of the
signing party.
Steve Kille and the IETF OSI-DS wg have already defined a means of deriving a
string from a Distinguished Name in RFC 1485, which was designed to meet this
requirement:
| There is a need for a format to support human to human communication, which
| must be string based (not ASN.1) and user oriented. This notation is
| targeted towards a general user oriented system, and in particular to
| represent the names of humans.
Assuming the CA used a "user-friendly" naming model, would not the Subject name
(in combination with the unique identifier) be sufficient for advising of the
claimant's identity? If these were not sufficient without a naming extension,
then I'd think the extension would need to be critical for processing.
Various applications might wish to display different kinds of attributes of
the subject, such as their telephone number or photograph. At one extreme,
all their X.500 attributes would be present in the certificate.
BTW, under the proposed resolution could there be multiple Extension with the
same OID in a Set? Does the "UNIQUE" keyword mean there can only be one
type definition of an EXTENSION info object with a given OID?
------------------------------
CN=Mark Wahl, O=ISODE Consortium, C=GB