SPKI was deprecated for SDSI[1] (also done by Rivest), both of which AFAIK haven't been touched in ~20 years (which is fine by me, if the theory and implementation are solid, but SDSI has CORBA/J2EE smells all over the RFC from what I remember. Lightweight, eh...)

[1] https://people.csail.mit.edu/rivest/sdsi11.html

> SPKI was deprecated for SDSI

No, it's the other way around: SDSI was deprecated for SPKI, which took a lot of its ideas about naming from SDSI.

> both of which AFAIK haven't been touched in ~20 years (which is fine by me, if the theory and implementation are solid, but SDSI has CORBA/J2EE smells all over the RFC from what I remember. Lightweight, eh...)

SPKI is indeed old, but the fundamental ideas are really good, and some of them (the cert calculus) are timeless. It needs a v2.0 to update the recommended crypto, specify some more use cases and so forth. But it's really, _really_ good, far better than XPKI and extremely capable.

And still pretty lightweight.

Hey, if the conceptual grounds are sound, which I'm guessing they are, since... I mean, Ron Rivest, age doesn't quite matter w/r/t the timeless elements. Rijndael is mathematically sound, and honestly I've got more trust in older algorithms than newer ones if only because there's been more time for the populace to vet it[1] presumably fortifying it with time.

All of the resources I've searched for are fairly old, do you have anything more recent that I can read up on? I see a 2006 paper, but not much other than that.

[1] Though I'm well aware that having an open-standard available for a long time doesn't mean squat, as evidenced by Heartbleed-esque bugs.

Edit: Reading the '00 "A Formal Semantics for SPKI" Howell, Katz, Dartmouth. This is what I was looking for.

I wonder what you think so far.

In particular, I liked the tuple-calculus they define; it can be extended to support just about any permission I can think of (although it does require reversing DNS names, which is slightly ugly).

I have a scheme to release a v2.0 of the standard someday in my copious free time.

Sometimes it's good to use asymmetric crypto, and those RFCs could perhaps be suitable for that. My impression of the parent comment is not that of a preference for asymmetric over symmetric, however, but rather of a lament that key-based crypto is defeated when attackers learn keys. After all the complaint about secret keys applies just as well to private keys.