[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: specification language?



>On Thu, 7 Mar 1996 Jueneman@gte.com wrote:
>
>> >Taking X.509 and flatenning some of the most egregious levels of 
>> >hierarchy could go a long way to getting things started, even if it just 
>> >suggests some of the data types to use. 
>> 
>> What do you mean by "hierarchy" in this context? Are you referring to the 
>> hierarchy of CAs, or to something else?
>
>Whooo - I can see that what I wrote could be confusing - I'd better 
>clarify fast!
>
>When I say, flatten hierachies, I'm referring to the data types used to 
>build the certificate, and *NOT* any ceritificate chaining. For example, 
>X.500 DNs are of the form 
>
>name ::= sequence of rdn
>rdn  ::= set of ava
>ava  ::= sequence { attr string, value string}
>
>which LDAP flattens to 
>
>name ::= string -- where the raw X500 name is converted to ascii using 
>               -- a few simple rules (see RFC1485)

OK, now we're on the same page, at least!

I understand what you are trying to do, but there are a few problems to be 
solved.

1. ASCII in general is not sufficient for international applications. (LDAP 
needs to be fixed to support BMPString/Unicode).

2. Sometimes it is necessary to use multivalued RDNs in a name, in order to 
disambiguate them. For example, if there are two people of the same name in an 
organization, it may be necessary to use commonName plus serialNumber (employee 
ID) to define which one is which. Likewise, if people have titles or roles, a 
multivalued RDN is probably the most appropriate way to incoporate both the 
name and the title into a single node of the hierarchy.

3. The issue of attr strings is likely to be a religious one. Personally, I 
strongly prefer a unique attribute encoding, complete with OID, so that both 
the syntax and the semantics of that attribute can be precisely identified. 
Even if I don't understand that particular attribute, I will at least _know_ 
that I don't understand it. However, I realize that some people might be 
willing to put up with a unstructured mess of names, addresses, titles, fax 
numbers, telephone numbers, and maybe even pictures and logos -- essentially a 
business card view of the world. In my view that is simply too difficult to 
parse, but I guess there is no accounting for taste.

In summary, I guess that I don't feel that the DN hierarchy is all that 
egregious, once you consider what it has to do.

But then, we are still trying to decide that, aren't we?



Bob

Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Jueneman@gte.com
1-617/466-2820

"The opinions expressed are my own, and may not 
reflect the official position of GTE, if any, on this subject."