Steve,
Our messages have criss-crossed each other in real time. If
it weren't for the fact that I think the subject deserves
general discussion and the thoughts of others, a phone
call from Waltham to Cambridge would certainly have been
more efficient!
I forgot to reply to a couple 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 previous message provided by thoughts on the subject.
I guess I missed your point. Were you suggesting that we should go
ahead and implement a new UID feature in advance of PEM adopting
X.500 1993? What do I do for our users who want to use TIS-PEM
or Jeff's Macintosh version?
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
flexibility 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.
I think you were right the first time (IFF you had the same set of attributes
I had in mind, of course! :-) ). But maybe this is just a minor timing issue?
Perhaps Jon will publish those same recommended attributes in the
central registry?
I remember seeing the display-as-best-you-can requirements, although
I haven't been able to find it today. I am a little concerned that some
implementations may have overlooked this requirement.
However, if implementations were to allow the ENTRY of otherwise
unknown (to that implementation) attributes in hex and printable string,
etc., if and as required, then we might be able to accomodate some
of these unforeseen issues (of which there will probably be many more).
Any chance of adding that as a requirement to Jeff's list?
Bob