[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
Carl Ellison wrote:
>
> At 02:04 PM 6/11/96 -0700, Peter Williams wrote:
> >Im
> >assuming the SDSI models are coherent with SPKI!
>
> SDSI has solved one of the biggest problems I've seen with X.509-like certs
> -- the lack of a global name space.
X.509 does not have a big problem with name spaces. It provides a name
syntax, and that can be administered in any manner a user group wishes.
That SDSI model chooses the name admintration model first pratically advanced by the
NADF - namely a collection of large adminsitration-managed domains (with
CA's as roots), in which there is full freedom for each node=naming-context
to choose the names of subordinates - is great. SDSI is pure X.500, using a
selected profile based on disjoint ADDMD domain adminsitration (to be formal)
and a single class of named object, where each naming element (arc) is a autonomous
naming context (phew!)
The other signiificant reason why X.509 has not a problem is
that one need no longer bother with X.500 names whatsoever,
at the behest of many who have long since stopped listening
to the above argument, regardless of merit. We can
now all choose our own syntax and format, be we
EDI, Internet, SDSI, or whatever.
The final reason why X/509 has no problem, as there
is absolutely no need to use the BER/DER encoding rules.
So lets use S-expr as the canonical encoding. Hopefully
someone will assist us have international char sets...
X.509 v3 certificate directly facilitate names based on SDSI name
forms "Bob's Cat's recent-meal's (mouse's) public key". The
difference between this and and encoding "cn=Bob; cn=Cat; cn=recent-meal"
is hard to tell, but its irrelevant. Lets use the anglo-saxon-biased
format with its possesives and western char sets. Why not! (sic)
Rivest and Lampson have recognized that
> there is no such thing -- that all names are local. To me, this smacks of
> early Relativity work and I think we're all convinced that it's a Good Thing.
R/L re-introduced a classical naming scheme, the like of which has
been around for 10 years. I was a student when I read Lampson's
NATO seminar texts on this distributed system's naming stuff!
It hasnt changed very much! X.500 also facilitated local naming
as inherited much of DEC early work.
>
> They took that and extended it to allow a nice method of defining groups.
Yes. But I didnt really follow this bit. Ill try harder.
>
> They've chosen an S-expression encoding with which some SPKI folks quibble,
> but to me the encoding isn't anywhere near as big an issue as the contents
> of a cert. It's very important, IMHO, to throw out the kitchen sink and
> reduce certs to basics.
The difference between an S-expression encoding and the X.509 D/BER
encoding is so minor as to not hopefully be an issue. Anyone
who objected to ASN.1/DER must reject S-expressions, as ASN.1
may have S-expression encoding rules, binary or text,
as BER and S-expressions are both just tag-(length)-value recursive
structures. S-expr has a text tag, DER has a binary number tag chosen
by the user.
>
> There is one apparent divergence between SDSI and SPKI which will work out
> shortly, I predict: SDSI as described in Ron's paper is strictly
> name-centric. I have a way to merge key-centered certs into that structure,
> but I haven't written that up yet much less gotten agreement from Ron and
> Butler that it fits in their scheme.
This will be interesting. As long as you *merge*, this will be great.
We will soon have reinvented the X.509 syntax, and the generic
authentication framework capable of all these various models.
>
> Beyond that, the person I mentioned who is implementing SPKI is inside a
> large corporation where SDSI's name linking isn't as important as it is
> among us web crawlers. The corporation has a single name space. However,
> as they extend services to their customers, SDSI's naming will become very
> important, IMHO.
Naming is a management issue; few people bother to think through
name management until their deployment size hurts or costs too much.
This is why Verisign chose to ignore name mangement in our Class 1 cert
service, and let users choose their own names. After a while,
I suspect consumers will tell us they care more...
>
> Beyond that, SDSI is a little weak in attribute certification. It's all by
> group definition. Blaze/Feignebaum/Lacy have a good start at improving that
> and I've been working with one other person on an enhancement which should
> save a great deal of time and effort in dealing with certificates.
>
> So -- what I write as my offering for the RFC isn't going to be straight
> SDSI, but it will certainly use that work!
great. So far Ive heard NOTHING which isnt catered for in the
X.500 naming model, and expressible in the X.509 syntax with an
S-expression or any other recursive TLV-encoding.
If one uses S-expr, and has the public key before the name,
really quite irrelevant! All we need to do now is reinvent
an extension mechanism...
Is all SPKI mail of this quality; Id heard it
was mainly an anti-ASN.1, anti-ISO rant, so didnt subscribe
given the irelvancy of these topics to the issues.
As Warwick Ford says - its only syntax!
>
> --------back to your regular channel---------
>
> - Carl
>
> +--------------------------------------------------------------------------+
> |Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
> |CyberCash, Inc. http://www.cybercash.com/ |
> |207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
> |Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
> +--------------------------------------------------------------------------+
References: