You've (quite correctly, I would say) pointed out that the standard solutions have lots and lots of flaws.
Then you've seized on SPKI as the answer; in that lies an assumption that there should be a standard.
Why? What is it about crypto and programming and human trust that tells us that this is amenable to standardisation? We know that security is really hard, we know that people come in and attack from all angles, yet apparently we can fit the #1 widget in place and security becomes "no problem?"
Instead, I propose that security does not fit will with standardisation. Rather, you have to get into each and every application and create your requirements. When you do that, independently of every prior assumption, I think you will be surprised to find that the crypto answers that are needed are (a) not covered by any standard and (b) are a lot simpler than provided by any standard.
I say more of this over on my blog where I introduce a hypothesis: "It's your job. Do it. (https://financialcryptography.com/mt/archives/000873.html)" That is, a standard won't solve your real problems; you may well be better off suffering the need to invent your own protocol, and do your own crypto. It's not easy, but IMO it is a lot more tractable that solving security problems generated by the poor selection of someone else's security model.
If that doesn't work, consider this: It's also a lot more fun :)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
What alternate to SSL, OpenPGP, SSH, IPSec is there?
Date: 2007-03-03 04:44 pm (UTC)Then you've seized on SPKI as the answer; in that lies an assumption that there should be a standard.
Why? What is it about crypto and programming and human trust that tells us that this is amenable to standardisation? We know that security is really hard, we know that people come in and attack from all angles, yet apparently we can fit the #1 widget in place and security becomes "no problem?"
Instead, I propose that security does not fit will with standardisation. Rather, you have to get into each and every application and create your requirements. When you do that, independently of every prior assumption, I think you will be surprised to find that the crypto answers that are needed are (a) not covered by any standard and (b) are a lot simpler than provided by any standard.
I say more of this over on my blog where I introduce a hypothesis: "It's your job. Do it. (https://financialcryptography.com/mt/archives/000873.html)" That is, a standard won't solve your real problems; you may well be better off suffering the need to invent your own protocol, and do your own crypto. It's not easy, but IMO it is a lot more tractable that solving security problems generated by the poor selection of someone else's security model.
If that doesn't work, consider this: It's also a lot more fun :)