[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: yet another <auth> type
Dave Kemp:
>
>
> It sounds like a duct-tape patch for the fundamental limitation of
> SPKI certs.
>
> The premise of SPKI is that persistent identities are an unnecessary
> middle step between the public key and the "stuff" (names, email
> addresses, priviledges, etc) to be attached to that key. Therefore
> persistent identities have been eliminated as a concept from SPKI.
>
Ouch.
That stung.
But only for a minute: the same minute it took to remember that SPKI
does not eschew name certificates, only certificate formats which are
only useful for naming. I can't find fault with your statement of
SPKI's premise, but perhaps with its application: persistent identities
have not been eliminated as a concept, but as a requirement.
This is not a patch on a problem, this is another mechanism to provide
more flexibility on an emergency basis, particularly in places where
limitation of impact is desired. Name certificates can still be used
for what they are good for: as evidence for humans who issue privileges
to keys, with all the benefits you mention. So, no, we don't *require*
these "contortions", we merely *allow* a more flexible mechanism in cases
where it is desirable.
Also, the idea was not mapping *certificates* but keys. I assume you
didn't mean that, but wanted to make sure no one misunderstood what we
were saying.
> "Every problem can be solved with another level of indirection."
> -- ???
As in certifying privileges to names, you mean? :->
brian
Brian Thomas, CISSP - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@primary.net
One Bell Center, Room 34G3 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 235 0162