[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: yet another <auth> type


In message <199702241727.MAA19145@argon.ncsc.mil>, David P. Kemp writes:
>Better start scratching off that "S" thing from SPKI :-).
>      dpk
>"Every problem can be solved with another level of indirection."

Not so fast, i should say. If you want to do key replacement just
because, you can just delegate all authorizations to the new key (if
an auth is not-to-be-delegated, then you contact the issuer - but
that's what i'd like to happen even if X.666 certificates were used).
If the key changes because it was stolen/broken, then i want the
certificate issuer to be aware of the fact; user convinience at 
this point is secondary (to me):
a) if the key was broken because it was short, then i "penalize"(*) the
 key owner for not using the right set of parameters (this shouldn't 
 actually ever happened, cause i should have checked the key
 parameters when i issued the certificate)
b) if the key was stolen, see (a)
c) if a major cryptanalytic breakthrough has happened, that means
everyone's keys can be broken, so i want to switch to another
cryptosystem - new keys/auths for everybody.

(*) by making him request new auths; this doesn't mean i want to
penalize him, but that this is an acceptable policy, given the
circumstances. Meanwhile, CRLs take care of the rogue key.

These are my opinions anyway.
- -Angelos

Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface