The following discussion in the DCDev hub was most likely the cause of the change(s?):

- [2010-09-01 19:12:10] <Pretorian> KEYP state " followed by a base32-encoded cryptographic hash of either the certificate directly (which is appropriate in the case of a self-signed certificate), or a certificate providing the base of a valid signature chain (which may be more appropriate a CA-signed certificate). "
- [2010-09-01 19:12:25] <Pretorian> Do we or don't we need to specify which 'or' is applied?
- [2010-09-01 19:14:46] <Pretorian> I'd change the URI to be ":1234/kp=SHA256#foobar"
- [2010-09-01 19:15:16] <Pretorian> I dislike to use / as delimiter in this case. 
- [2010-09-01 19:15:44] <poy> i thought it would always be the first case (hash of the cert itself), since the purpose is to make sure that the cert received is the one we were expecting. how it is signed and by whom can then be checked once the cert has been received.
- [2010-09-01 19:30:29] <Quicksilver> a signed cert has no meaning for us ...  important is only that the cert shown by the hub is allways the same ... and that its the hub you received the address for ...  a ca is only there for binding a  virtual entity to a real one.. which we are not interested in ... as we are not companies trying to sell stuff
- [2010-09-01 19:31:46] <iceman50> i.e paypal needs  ca
- [2010-09-01 19:35:58] <Quicksilver> also there were already attacks were CAs were compelled to validate fake certs by a government as valid to allow spying on  TLS connections .... 
- [2010-09-01 19:38:11] <Quicksilver> e.g.  an attacker interrupts the connection and shows you a real looking cert signed by  CA from bananarepublic A ... attacker pays A money to compell  CA to valiudate their cert ... voila attack succeeded.. and your browser will probably not complain as the CA is valid... its just a bit implausible that paypal gets signed for example by some carribean CA ... but your browser won't mind to much...
- [2010-09-01 19:38:41] <iceman50> weird
- [2010-09-01 19:39:01] <poy> same opinion as me then, so in Pretorian's quote, always choose the first "or" case, right?
- [2010-09-01 19:39:01] <Pretorian> iceman50: Hm?
- [2010-09-01 19:39:19] <poy> Quicksilver: i thought you proposed KEYP?
- [2010-09-01 19:39:51] <iceman50> well unless you specifically check the cert yourself everytime you go through an encrypted channrel
- [2010-09-01 19:39:53] <Quicksilver> no not my preposition... and KEYP has nothing to do with CA ... for us KEYP is way better..
- [2010-09-01 19:41:20] <Quicksilver> the trick in all cases is  use the CA for the first time to verify a cert.. in all later cases compare the cert to the cert that has been shown to you before i.e. do what KEYP does ... sadly thats not the common case for browsers... thats what you do when you use putty/ ssh client ... comparing current cert to last cert
- [2010-09-01 19:42:21] <poy> KEYP's only use is when connecting via a hub list / web site, correct? after that clients can handle that cert comparison themselves.
- [2010-09-01 19:42:49] <Quicksilver> yes and no ...
- [2010-09-01 19:43:12] <Quicksilver> keyp is a way to store the cert.. just keeping it behind the hub's address... but KEYP is also there for client-client connections..
- [2010-09-01 19:43:32] <Quicksilver> and well yes it bridges the GAP between hub and hublist
- [2010-09-01 19:43:47] <Quicksilver>  (if the hublist is given to you via https)
- [2010-09-01 19:44:22] <Quicksilver> in the ideal case client creaters would store keyp for hublists in the clients... use these to verify the hublists.. whcih give  keyp of hubs...  voila  all validated..