I think you worked on this far more than me, and I think your work on this was far more important than mine. Mainly, I recall you hosting the collaborative workshop in INRIA and my pleasure at red wine and fresh fruit for lunch, from the refectory. Happy days! I don't disagree with anything you say Christian. Your point is (to me at least) people want simpler forms to use in everyday life. If however, you drive X.500 into use for structural naming against government process, documents, your legal status against other people, rank (in the military) then these complexities surface very rapidly. Lying underneath, is the problem in the US where some people never completely recover from identity theft because these structural forms were not properly respected, and simpler use of names and identity were overwritten. When you fill in paperwork, which is going to mint a digital identity, there is what CN and SN have become. When you want to find the correct instance of somebody against the 1000 other people with "the same name" it becomes important which field was used for which element. X.500's complexity reflects goal-seeking to "but what is the functionally correct attribute in a model, for this data" when names tend more towards "what do you call yourself, and how unique is this in context" cheers -George On Wed, Mar 3, 2021 at 10:20 AM Christian Huitema <huitema@xxxxxxxxxxx> wrote: > > On 3/2/2021 4:00 PM, George Michaelson wrote: > > > X.500 is complicated because names are complicated. > > Well, no. George, I worked on X.500 at the same time you did, and my > conclusions are different. X.500 names main source of gratuitous > complexity what that they embedded an arbitrary hierarchy. If I remember > correctly, the name hierarchy in X.500 embedded things like country > name, telecom company name, city, street, company (aka, organization), > department (a.k.a., organization unit), maybe several levels of those, > and then common name. Some attributes did not identify the person at > all, but where there to route the query to relevant database. Many of > these attributes are useful when searching for "Jane in Marketing", but > the fact is that pretty much each of those attributes have different > possible values like short or long versions, and that they are probably > not all required to identify the person. In order to manage the system, > users were expected to pick a specific subset of "distinguished" > attributes, which would have enough routing information in them to find > the relevant database and then uniquely identify an entry in that > database -- that's why the X.500 names in certificates are called > "distinguished names". Suffice to say that people found it way easier to > refer to "jane@xxxxxxxxxxxxxxxxxxxxx". > > -- Christian Huitema >