[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: spec for wire format of SPKI cert
thanks for your observations.
I agree that spki.txt hasn't captured the syntax as concisely and
concretely as we need to have it. I will add a BNF section for that.
We have not rejected the SDSI syntax. The desire for S-expressions
continues to come up and I'm strongly tempted to provide a
binary-to-S-expression translator, not just binary-to-RFC822.
The SDSI name semantics, on the other hand, is something we have
enthusiastically endorsed and adopted within SPKI. If that's not clear from
spki.txt, then my writing is worse than I thought :).
Your observation about the traditional split between authentication
and authorization is well made. I think you've tried to express what has
been driving us -- that the on-line world has changed radically and the old
split isn't the natural mode of operation any more.
I prefer to discuss this in terms of ACL use. Brian Thomas came up
with a batch of great examples of the problem with ACLs. Back when
computers were single lumps of hardware with single all-powerful owners, it
made sense to have ACLs. The hardware was as trusted as you could get
(since ACLs require trusted storage and processing) -- so you authenticate
someone first and then use the ACL mechanism to authorize them. However,
when delegation of authority is fragmented and distributed, as are the
computing resources, and the user community gets very large, ACLs break
under their own weight -- if not the weight of the ACL itself, then the
weight of the machinery which controls modification of the ACL.
At 09:02 PM 8/27/96 -0700, Peter Williams wrote:
>So, I like what I see (and Im biased!) in the emerging model, where I can
>the blatent NIH agenda, though have considerable legal worries from the
>the argument concerning the role of TTPs. A reliable liability model
>constrained data handling with well-defined meaning; and SPKI certs
>sometimes seem to be self-defining semantically; and this property makes
>life difficult if the certs are ever to control commercial risks,
>control hazardous, or military weapon systems.
I don't see any problem here. I can imagine SPKI certs used immediately by
DMS or even NSA-internal top secret applications, as well as by VISA,
I helped with a project once to use Fortezza cards to permit access from the
Internet through a firewall into the milnet. We were forced to permit
access only if the user had a valid Fortezza cert because the user community
was too big to permit an ACL and the Fortezza cert gave no authorizations.
It *did* have a security clearance encoded (in the key field, if I remember
correctly) so we might have used that. If DMS wanted to define its own
<auth> for access through that firewall proxy, they could do so immediately
without involving any TTP or standards body (forgetting the fact that DMS
itself is governed by something like a standards body). If they want to say
that the <auth> for access through that firewall is:
FOOBLATZ: "We're here!"
that's up to them. The firewall proxy is coded to recognize that string,
and make sure it was delegated properly from the DMS root. The DMS root
starts issuing SPKI certs:
FOOBLATZ: "We're here!"
and so on, down to the users.
The strength of this process has nothing to do with blessing by a standards
body or the involvement of a TTP. It has to do with the strength of the
security of the policies, equipment and personnel of the various certificate
issuers along the chain. It has especially nothing to do with the choice of
spelling for an <auth> field.
>Its disappointing to see the rejection of the list-based SDSI cert format.
>striking structural similarity to X.509/DER lists one should not be suprised,
I don't see the similarity to X.509/DER -- but I'm glad you do. Please
don't explain it to me, at least for a year or so :). We appear to agree on
the beauty and value of SDSI. Since I see SDSI becoming very close to SPKI,
that suggests to me that you and I may be in violent agreement after all
about SPKI. I would like that.
|Carl M. Ellison email@example.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 |