Bob,
I forgot to reply to a copuple of the points in your message.
We agree on the utility of using ID numbers to distinguish among
multiple instances of people with the same name at the same company,
etc. The question, as you said, is how best to encode this
information. My previuous message provided by thoughts on the subject.
Anyone operating a directory can, in principle, define
"private" attributes and use them. You don't have to register with
ANSI to do this, nor does your registration grant you any special
privileges with regard to defining attributes, object classes, etc.
Regstration with ANSI can provide you with an arc of the OID tree and
you could use that to generate OIDs for the attributes you define.
However, if private are distinguished attributes the implications of
having private attributes are not wonderful, as you can imagine.
The PEM RFCs do address this issue, I believe, stating that
unknown attribute types wil be displayed as octal (or hex?) strings,
and the attributes values will be displayed as best they can (e.g.,
printable strings are easy). I am very sensitive to this issue as I
was a staunch proponent of defining the full set of attributes to be
used in certificates in PEM, and even imposing constraints on
structuring. However, I was prevalied upon to remove those
restrictions to avoid imposing constraints on DNs that might be
incompatible with the directory schema that PEM users might adopt.
Thus PEM got out of the attribute and object class constraints
business. That too is why we described the list the IANA will have
(though we have not provided it to Jon yet), i.e., to allow
felxibility in expanding the set of attributes used in certificates,
but also to provide a central registry for PEM developers to use when
deciding how to deal with (display/prompt) these attributes.
Steve