Mark:
Thanks for the comments.
(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.
Good point. Perhaps VisibleString would be best (excludes control
characters). Advice from character set experts welcome.
(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.
If the only information needing to be displayed could always be derived
from the distinguished name then there would be no need for this
extension. But, as you point out yourself, various applications may
want to display attributes of the subject (such as telephone number or
photograph) which are almost certainly NOT part of the DN. In our
organization, for example, we want to display department number, but
this happens not to be part of the DNs in our X.500. It is not possible
to reliably display such information unless the verifier also has
signed operations to a trusted directory server - not a good assumption
as one of the big attractions of these PK systems is the ability to use
untrusted directory servers. Hence, all information to be displayed
must be in the certificate - if it is not in the DN then it has to be
in a new extension field.
Following on from your comment, it might be preferably to have some
more flexible structure for this extension than just a PrintableString
- perhaps make it a set of X.500 attributes, so that the application
can choose just which ones to display. An appropriate name for the
extension would then be SubjectAttributes. This would satisfy the
original requirement. There could be some objections to the added
complexity, but I think I could go along with it.
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?
Every extension type must have a unique OID. However, there can be
multiple instances of the same extension in one certificate if
required.
Warwick Ford