pem-dev
[Top] [All Lists]

Re: Use of ASN.1 in certificates

1995-08-01 08:12:00


In summary, it does not appear that there is is anything that is inherently
wrong with ASN.1 per se. The fact that it is an international standard that is

       Other than complexity and unnecessary generality?

I don't think that we should condem "unnecessary generality". The problem
is that the confussion surrounding the attempt at generality produces a
product less general than is needed.

For example the complexity of the syntax and data structures means that it 
is not possible to compactly describe ASN.1 in ASN.1. That is not a trivial
problem it breaks many systems based on dynamic synthesis and compilation of
code.

The "generality" of the character encodings means that applications have to 
treat six different character encodings, none of which is UNICODE. The basic
fault is that where a general mechanism was required they simply enumerated
their current needs. That does not provide generality, it builds in 
obselescence.

ps.  No human factors?  It will all be taken care of by GUI front-ends?
Try again.

When I try to break systems I attack the levels of abstraction looking for
a mismatch in the assumptions on each side. I am more than a little sceptical
as to the safety of attempting to cover up a botched name system with a
fancy graphical front end. That simply means another mechanism to fool the
user.

I know that Lotus notes goes down this track but the functionality that
is required is not exceptionaly great. Lotus notes does not pretend to
be adequate to provide security adequate for nuclear facilities for example.
It is a collaboration system not a financial trading system.

We have to address such concerns. I beleive that the Internet naming 
approach is adequate for these tasks and simpler to implement and use. 
I simply do not accept arguments of the form "very few people will need
that capability, therefore we will build something broken".


I see the future naming standard for the internet as being based on URNs.
The form of the name being:

URN://org/w3/*                  The subset of namespace granted to W3.org 
                                by Internick. 

URN://org/w3/people/hallam      The subset of the W3.org namespace assigned to 
                                me by w3.org.

These are much easier to parse than X.509 DNs they actually convey a meaning
and do not require Base64 encoding for transport in mail. There is an extant 
registry infrastructure, there is a wide degree of familliarity with similar 
names. There is a well defined ownership relation for these names.

X.400 style names may be graqndfathered through a non resolvable hierarchy
lookup :

URN://id/x.400/ou=greenpeace/c=france/  [some rfc suggestion]

We do not need resolvable names in this case we merely need uniqueness. Thus
we can finese the entire lookup palaver, there will be a lookup scheme 
avaliable at some point we can assume. From the security point of view we 
only care that the strings are defined as being names and that the 
equivalence relationship for the names themselves is well defined. 

If we consider the semiotics, if Fred and Freddy both denote the same person
we may say that at the semantic level Fred = Freddy. That does not mean that
we have asserted the equivalence of the names, merely that to which the names 
refer. 

We therefore need only consider for our purposes name equivalence at the 
superficial syntactic level, mechanisms for escaping characters for example,
we are only concerned with obtaining a cannonicalisation proceedure. We have
no interest in or need for knowledge of the sematics of the name, it is up 
to the owener of the name to make such decisions.


A certificate thus becomes an authenticated assertion made within the context
of the names within it. The names form an ontology and that ontology is defined 
by namespace ownership.


The URN scheme forms the basis for a system of knowledge, the X.400 system does 
not. The lack of reflexivity prevents it being a credible contender in this 
field. URNs provide greater power and are easier to implement. I therefore 
strongly recommend that URNs are one form of name considered by these groups.


                Phill Hallam-Baker

------- End of Forwarded Message


<Prev in Thread] Current Thread [Next in Thread>