[Standards-JIG] certificate and private key retreival

Ian Paterson ian.paterson at clientside.co.uk
Tue Mar 16 13:47:02 UTC 2004

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.

IMHO we should store certificates on each user's own server. then senders
would not need to include a certificate with every message, and receivers
can cache other users' keys - and only download certificates from other
users' servers when really needed.

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

- A client should be able to request a list of any other user's public
certificates. The result should include information about each certificate
(ID/date/signing authority/bit-strength/algorithm...).
- The client can then choose, request, and verify each certificate that it
needs and cache the resulting keys.

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.

- Ian

More information about the Standards mailing list