[JDEV] Signed & encrypted messages

[Al Sutton]

I mean the sender of the key would sign the key (i.e. the keyserver).

If user A has their public key stored at keyserver X, X would have a signing
key that it would use to sign the public key of A each time a request was
served for A's key (so A's key is signed with X's signing key).

What I have in mind is slightly different to the signature used in X509
certs. The example is thus;

If user A wishes to store their public key at key servers X, Y, and Z (to
ensure it is always available) they can pass the information to each server
as they wish. When X, Y, or Z respond to a request for the key of A they can
respond with the information from A (the signature or X509 cert), and sign
it with their own key. That way if the user requesting the key for A can
tell the source of the key response (i.e. X, Y, or Z) and attach a level of
trust to it.

>From what I know X509's allow the issuer to add a signature, but don't have
the scope to hold the identity of the keystore from which the key was
retrieved (which this method solves).

Does this make things a little clearer?

Al.

----- Original Message -----
From: "Mathew Johnston" <johnston at megaepic.com>
To: <jdev at jabber.org>
Sent: Sunday, May 27, 2001 6:58 PM
Subject: Re: [JDEV] Signed & encrypted messages


> Do you mean that the sender of the key would sign the key? Or do you
> mean that a third party would sign the key?
>
> So far, I think that the list of key exchange methods are manual,
> x509 via vcard or some other server side thing, or query response
> for keys - the sender would not be able to sign the key since the
> key is what they would use for signing (it would be sort of useless). :)
> If we want third party signed keys, X509 certificates would already fulfil
> that need.
>
> Mathew Johnston
>
> On Sun, May 27, 2001 at 10:15:33AM +0100, Al Sutton wrote:
> > I've read the draft and I'd like to suggest that a signature field is
added
> > to the response to a key query performed via jabber:iq:keyExchange that
> > represents the digital signature of the key returned.  If jabber clients
> > carry a list of public keys from trusted key holders (or a list is
easily
> > accessible to them), they could then indicate the level of trust placed
on
> > that key, as well as verifying that no modifications were made in
transit.
> >
> > Does this sound useful?
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev