[Standards-JIG] certificate and private key retreival
justin-keyword-jabber.093179 at affinix.com
Tue Mar 16 19:04:38 UTC 2004
On Tuesday 16 March 2004 5:47 am, Ian Paterson wrote:
> Justin wrote:
> > I also think we should include an optional way of attaching a
> > public key to the packet. This would be especially useful with
> > X.509, as such certs are often not stored locally.
> We need a certificate retreival mechanism since, before encrypting a
> message, the sender needs to know the receiver's public key. So why not use
> the same retreival mechanism for decryption? Especially since a
> certificate's signing chain can make it very big.
Good point. I must have been asleep when I wrote the 'send key' section of
the new JEP, because it wouldn't really solve anything.
The nice thing about X.509 is that it greatly simplifies security to the point
that even our mothers can understand it. This is why SSL/TLS is widely used,
but PGP is not. I was hoping to be able to extend this philosophy to the
Jabber world, so that for instance a bank could send secure alerts to their
customers without the customers having to fiddle with public keys. I now
realize that this is unfortunately not possible to do without the recipient
specifying at least _some_ credentials. In the case of a bank website, while
the session might be secured with SSL, the customer must always enter a
passcode of some sort before the bank can send him trusted data. This
doesn't translate well into Jabber if we want simple content delivery.
So much for that. :)
> Today, each user's public key is already available via the vcard JEP.
> However, access to certificates and private keys will be required for
> several JEPs in the future. So IMHO we need a new JEP (separate from
> JEP-0130) dedicated to public certificate and private key retrieval within
Agreed, this is where Jesper's JEP will come in, I think.
> People should be able to use their private key from any client anywhere on
> the net. Each user's private keys can be safely stored and retrieved
> (in-band over an insecure connection) from their own server (today via
> jabber:iq:private), as long as it has been symmetrically encrypted with (a
> hash of) the user's password.
Interesting idea, but of course one could not use the same password as the
More information about the Standards