[Security] XEP-0189 Update Proposal Part 1
dmeyer at tzi.de
Sun Sep 7 02:51:43 CDT 2008
Justin Karneges wrote:
> On Saturday 06 September 2008 14:21:25 Dirk Meyer wrote:
>> quick look at the source code of tlslite looks like that the algorithm
>> is encoded in the signature. Am I right?
> Could be. I'm not sure how the low-level formats really work. Were you
> looking at a format for DSA? I think there's one that includes the hash type
The HasAndSign function is not part of the X.509 object, it is part of
the RSAKey object. But if there is no real hash and sign function I
guess I have to specify it:
"A signature is generated by the using the given algorithm to create a
hash of the certificate in DER format and encrypt it with the private
key of the signer."
| <signature signer='identifier_of_signing_key' algorithm='sha1'>
> Just like with the fingerprint, I think you're going to have to either specify
> the format method explicitly in the XEP, or allow the format information to
> be passed along in attributes.
Maybe I just remove the fingerprint and add a key name that can be
anything, just like it is now in XEP-0189.
> Another issue: X.509 already has the ability to sign certificates. You have a
> User cert and a Client cert. Why have Client be self-signed, and then again
> signed by User, when User (acting as a CA) could sign Client in the first
Setting up a CA is scary ;)
The point is that creating a self-signed certificate is a one-liner. I
also want to sign by OpenPGP key with my RSA key in the X.509
certificate and the other way around. This makes it possible for you
to verify my X.509 certificate if you have my OpenPGP key.
>> Well, the expired is more or less useless, I agree. It is only here as
>> a hint. About the revoke: can you revoke a certificate and add that
>> information in the certificate? The problem is a have no CA and when a
>> client gets stolen, I want to revoke the certificate. My understanding
>> is that you have to check the CA for revoked keys. Without a CA I need
>> something else.
> The revoke would have to include a signature, otherwise you could revoke
> certificates that aren't yours.
No, the keys are stored on _my_ PubSub server, only I can change
stuff. Well, and the server, but I have to trust the server a bit
> See GnuPG, where the common practice is to create a revoke message at the time
> of key generation, keep it in a safe place, and then if your key is
> compromised or lost then you can broadcast the revoke message to the world.
> It's important to generate the revoke message before you lose your key,
> otherwise you can never revoke it.
I wanted to keep it simple. Here is a small use-case:
A new client with a self-signed certificate provides this certificate
to a client with my user certificate. Either out-band or using
link-local messaging and XEP-0250 with SRP. The already trusted client
uploads the certificate + the signature to the PubSub server. The new
client can now log in using SASL-EXTERNAL and all my clients can
verify that this is also my client for e2e encryption. Now the client
gets stolen. I add a <revoke/> to the PubSub node (only I can do that)
and the client can not log in anymore and all my other clients know,
that this client should not be trsuted anymore. This only works
together with SASL-EXTERNAL or the bad client can just remove the
With the XMPP server and PubSub I can make sure only I can edit
stuff. I was hoping by using these two components I can skip a CA and
complex revoke messages.
This is the Time Travelling Agency's answering machine. We're closed
right now but leave a message before the beep and we might have called
More information about the Security