[JDEV] Signed & encrypted messages

[Max Horn]

At 17:49 Uhr -0400 27.05.2001, Mathew Johnston wrote:
>I see what you mean now. I am not entirely convinced, however,
>that this is necessary when using X509 certificates since
>you are concerned with the integrety of the certificate, and the
>trustworthyness of the certificate authority, not where the particular
>copy of the certificate came from.

Exactly. Knowing where the key was stored is not at all helping to 
discover how "trustworthy" that key is. If I'd made a key/certificate 
for myself and labeled it "Bill Clinton", then put it to some key 
server, then the key/cert is still fraud, regerdless of how much you 
trust the key server.

The only way to be able to trust/cert if is it is signed/certified. 
In PGP, you use the web of trust or CAs for this; and with X509, you 
usually only use CAs (although there are attempts to do something 
like the Web of Trust with X509, too; IIRC Thawte is/was working on 
this).

Anyway, this also means it is not really a problem to request keys 
directly from other clients. Or to store them on the jabber server. 
Or to get them from any location. The security is for all the same. 
That's not the problem; the security is achieved by checking for the 
signers of the key, and if we know one or more of them to be valid & 
trustworthy, we can decide to trust the validity of the key; if we 
don't know any of the signers (or the signer is not trustworthy), 
then we simply can't trust the remote key. Point!
(For PGP keys, there is also the possibilty to use keyprints and 
transfer those over phone or via snail mail, this can be used as a 
different way to verify a PGP key - and to mark a key as "trusted" 
with PGP, you have to sign it manually anyway).



>Personally, I think x509 certificates
>are a good choice since there is already a lot of x509 infrastructure out
>there, and x509 provides us with specification of encryption algorithms,
>third party signing, key management, etc. I'd like to hear arguements for
>or against different key exchange schemes. I think we need the following
>key exchange properties:
>
>- ability to access users public key when user is not online

Both X509 and PGP offer this.


>- ability to verify authenticity of the key

Both X509 and PGP offer this.


>- ability to request key for use with particular algorithms

I don't see what this is good for. If I use OpenSSL to validate X509 
certs, I would support most algorithms anyway, and it will pick a 
supported one. If you use PGP, well, that supports all its 
algorithms, too, and gpg should support most, too.

Different algorithms also mean different keys... basically, what you 
mean is that a user should have multiple keys using different 
algorithms, but "tarned" as a single key. But the encrypted data I 
get is signed with exactly one of those keys; unless you want to send 
the encrypted data several time, for each key seperatedly... or maybe 
i misundertand you here?



>- ability to manually exchange keys (write down on paper and type
>   them back in, etc)

I am not sure this is very practical; PGP at least offers 
Fingerprints, which (as mentioned above) can be transported on a 
piece of paper or via voice. I don't know about X509; but I think 
this feature is not that critical (I might be wrong of course).


>
>I think x509 can fulfil the first three properties.

Same for PGP. The current clients all use gpg/PGP AFAIK (I might be 
wrong, never used any of the ones that support it, and mine all don't 
support encryption yet :( )
Anyway, there have been arguments about this before, and I must admit 
I am less sure than ever which one should be prefered. I don't see 
anything that would really make one more fit than the other; but OTOH 
keeping both at parallel seems like a possible future problem; i.e. 
if I use PGP keys, and you use X509, can we communicate? Of course, 
if all clients can at least decode/verify both, this would be no 
problem...

Hm, I want to use OpenSSL anyway for SSL support... and gpg is 
available for MacOS X, too, so i propably could stea... err, borrow 
from Gabber and Jarl ;)



>The fourth
>property would be up to clients. Since there may be more than
>one certificate (for each different algorithm) we can't really
>put them all into a user's vcard, since that would be too big.

I agree. I'd prefer if vCards would stay small. But maybe vCards 
should be signable? So we can verify they are real ;)


>However, someone mentioned that there is a way for clients to
>store data on a jabber server, to be querried for by other clients;
>this could be used to store the certificates. (can anyone comment
>on this further?)

You are talking about iq:private. Yes, this could be used, we could 
agree on one or two namespaces to store PGP keys and/or X509 certs.




>I'm not sure if this method allows for the naming
>of chunks of data, but if it does we can allow querrying for
>particular algorithms by using naming rules for each 509 certificate
>resource. When the querry is returned, a name should be given to the
>certificate so that it can be referenced when using it (so that
>the recipient knows which certificate is being used)
>
>In the end, this is all up to the Jabber Foundation to decide upon,
>of course.

Yup, but we can already collect data ;)


Max
-- 
-----------------------------------------------
Max Horn
C++/ObjC/Java Developer

email: <mailto:max at quendi.de>
phone: (+49) 6151-494890