The recent exchanges between Rhys Weatherley and Peter Williams, prompted
originally by contributions from Mike Roe and Warwick Ford with interjections
from me, have contained the seeds for several different threads, all of them
worth discussing:
Thread 1: "User-friendly" summaries of a user's "identity" claims, as opposed
to (in addition to) the DN content of the certificate.
I'm all for adding any information that the user feels would be useful, subject
to two caveats: (1) That the CA clearly state in its policy (the PCAs policy,
really) the extent to which it is accepting the responsibility (due diligence)
for verifying the user's additional information, and (2) that this information
be encoded in an appropriate set of attributes so that the _receiving_ user can
exercise some choice as to the format in which they will be displayed. In other
words, I want the originating user to be responsible for parsing the
information into appropriate attributes -- I DON'T want just a printable string
containing information as undifferentiated ASCII text.
This should NOT cause a proliferation of X.400-like keywords that have to be
used in the user interface, because these attributes are not in the DN and
therefore don't have to be entered in order to specify the user's certificate
accurately. User agents can do what ever they want as far as displaying the
incoming information, using either keyword=attribute_value or a more graphical
presentation format.
Subthread 1a: The appropriate choice for an encoding alphabet for such
purposes.
The issue of how obscure characters such as the @ sign :-) should be encoded is
a red herring, since the information in the certificate is SIGNED and therefore
will have to be filtered, BINHEXed, or whatever, no matter whether it is a PEM,
EDIFACT, or other kind of certificate. The encoding alphabet should therefore
be as rich as possible with respect to such symbols, as well as for
accommodating non-English alphabets, at least the roman varieties.
(In other words, the tilde, cadilla, umlauts, accents, and unique punctuation
(e.g., the Spanish upside down question mark and exclamation mark) required for
English, French, Spanish, German, and the other common European and North and
South American languages must be supported. I don't mean to discriminate
against the Russian or Hebrew alphabets, nor Arabic, Thai, katakana, etc.,
etc., I'm just not expert enough to know how to handle them all.)
Subthread 1b: The interesting, and hitherto unknown (at least by me) fact that
EDIFACT certificates follow different encoding rules than X.509.
Is an information preserving translation possible between the two forms, e.g.,
by a gateway? (I guess the gateway would have to be a trusted thrid party in
this case, if the encoding rules are inside the SIGNED portion?)
Thread 2: Extended possiblities for naming structures that don't conform to the
current "what God intended" :-) civil or geopolitical naming authority
assumptions. Examples would include the use of DUNS numbers, international
telephone numbers, Internet e-mail addresses, etc.
This message is already long enough, so I'll post my remarks on this thread
separately.
Bob
--------------------------------
Robert R. Jueneman
Mgr., Secure Systems
Wireless and Secure Systems Laboratory
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820 (rolls over to cellular and/or my house
if no answer -- have patience)