From jonathanD at k2.com  Mon Sep  1 09:30:39 2008
From: jonathanD at k2.com (Jonathan Dickinson)
Date: Mon, 1 Sep 2008 16:30:39 +0200
Subject: [Security] End-to-end encryption with JavaScript client
In-Reply-To: <48BA2C53.4070200@wp.pl>
References: <48B8FAFC.6050006@wp.pl>	<20080830111542.46d95c03@tiger>
	<9b58f4550808300945n54711f83j6e17603d6da26f84@mail.gmail.com>
	<87myiu30md.fsf@phex.sachmittel.de> <48BA2C53.4070200@wp.pl>
Message-ID: <A790BE8D83ECC3469047C2E344EABE6170BA4688A8@zamail01.k2workflow.com>

I think I get what he is saying. Your Javascript may be cached by your browser, which would open it up to tampering locally.

The JS over HTTP really depends on browser being 'proper'. They are supposed to warn you if ANYTHING downloaded is not over HTTPS. Images, JavaScript et al.

> -----Original Message-----
> From: security-bounces at xmpp.org [mailto:security-bounces at xmpp.org] On
> Behalf Of Bartosz Malkowski
> Sent: Sunday, August 31, 2008 7:30 AM
> To: XMPP Security
> Subject: Re: [Security] End-to-end encryption with JavaScript client
>
> Dirk Meyer pisze:
> > IF you have the script on your PC and not from a server. It makes no
> > sense to talk about e2e security when you receive your XMPP client
> > from a server just before you use it. Even better: most Javascript
> > files are send over HTTP, not HTTPS.
>
> I trust MY server. I trust files I received from My server.
> Communication Me<->MyServer<->He is secured in my opinion. But
> Me<->MyServer<->HisServer<->He isn't (I don't trust administrator of
> HisServer).
>
> But maybe You're right -- it makes no sense...
>
> --
> Bartosz Ma?kowski
> JID: bmalkow at malkowscy.net

From pavlix at pavlix.net  Mon Sep  1 17:13:08 2008
From: pavlix at pavlix.net (Pavel Simerda)
Date: Tue, 2 Sep 2008 00:13:08 +0200
Subject: [Security] Perspectives: Improving SSH-style Host
 Authentication with Multi-Path Probing
In-Reply-To: <87bpz92f8s.fsf@phex.sachmittel.de>
References: <87prnvuc4c.fsf@phex.sachmittel.de>
	<FB24EF2D-EA05-475F-8D75-7B5938CF68E6@simplicidade.org>
	<874p54ruy4.fsf@phex.sachmittel.de>
	<B8CAF6B0-0F64-4D02-80B0-4A5B95BDC854@simplicidade.org>
	<3307.1220010183.085980@peirce.dave.cridland.net>
	<10B3824F-0BDD-46F7-933B-9C3C9A330C01@simplicidade.org>
	<87od3b4qzk.fsf@phex.sachmittel.de> <48BAC22D.9060102@stpeter.im>
	<87bpz92f8s.fsf@phex.sachmittel.de>
Message-ID: <20080902001308.373725f6@tiger>

On Sun, 31 Aug 2008 20:47:47 +0200
Dirk Meyer <dmeyer at tzi.de> wrote:

> Peter Saint-Andre wrote:
> > Dirk Meyer wrote:
> >> Peter wants to give XEP-0189 more love, I guess this is something
> >> that should be in it. Also the user/client keys. When he is back I
> >> can work with him to add all that stuff.
> >
> > Sure, let's do that. Or feel free to pull the XML out of SVN and
> > start working on it. :)
> 
> I just looked at it and PEP and some other XEPs and there are some
> things I do not like. Maybe these XEPs need a small update for this
> use-case.
> 
> 1. PEP says the last_item should only be send if the priority is not
>    negative. But all bots have a negative priority and will never get
>    the updates. Maybe an extra config option for PubSub/PEP: also send
>    to negative priority?

http://www.xmpp.org/extensions/xep-0060.html#filtered-notifications

No priority in PubSub.

In PEP:

"If a subscriber subscribed using a bare JID <localpart at domain.tld> and
a PEP service has appropriate presence information about the
subscriber, the PEP service MUST send one notification to the full JID
(<localpart at domain.tld/resource> or <domain.tld/resource>) of each of
the subscriber's available resources that have specified non-negative
presence priority and included XEP-0115 information that indicates an
interest in the data format."

I believe that if some resource indicates an interest, it should get
what it wants.

+1 for a change in the XEP

> 2. I like the fact that I get a notification when I start my client
>    when there is a new item (if it is configured that way). But I also
>    want to be notified when something was deleted (certificate
>    revoked). What I would like to have is that I get a notification
>    from the server that "something has changed since I was last
>    online" so I can get the whole tree of certificates.

You should not need to watch deleted item. Certificates are revoked,
not deleted, revocation could be just easily announced as a new item.

> Maybe move that discussion to the pubsub list? /me needs to subscribe
> to that list, too :)

Maybe, I'm not sure.

> And something else I also added a note in my XEP proposal about the
> TLS verification: how should keys look like. XEP-0189 now uses xmldsig
> which IMHO is very complicated. People now how a keys look in PEM
> format. Maybe just use this?
> 
> 
> Dirk
> 


-- 

Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

From dave at cridland.net  Tue Sep  2 02:50:50 2008
From: dave at cridland.net (Dave Cridland)
Date: Tue, 02 Sep 2008 08:50:50 +0100
Subject: [Security] Perspectives: Improving SSH-style Host
 Authentication with Multi-Path Probing
In-Reply-To: <20080902001308.373725f6@tiger>
References: <87prnvuc4c.fsf@phex.sachmittel.de>
	<FB24EF2D-EA05-475F-8D75-7B5938CF68E6@simplicidade.org>
	<874p54ruy4.fsf@phex.sachmittel.de>
	<B8CAF6B0-0F64-4D02-80B0-4A5B95BDC854@simplicidade.org>
	<3307.1220010183.085980@peirce.dave.cridland.net>
	<10B3824F-0BDD-46F7-933B-9C3C9A330C01@simplicidade.org>
	<87od3b4qzk.fsf@phex.sachmittel.de> <48BAC22D.9060102@stpeter.im>
	<87bpz92f8s.fsf@phex.sachmittel.de> <20080902001308.373725f6@tiger>
Message-ID: <9235.1220341850.474535@peirce.dave.cridland.net>

On Mon Sep  1 23:13:08 2008, Pavel Simerda wrote:
> On Sun, 31 Aug 2008 20:47:47 +0200
> Dirk Meyer <dmeyer at tzi.de> wrote:
> 
> > Peter Saint-Andre wrote:
> > > Dirk Meyer wrote:
> > >> Peter wants to give XEP-0189 more love, I guess this is  
> something
> > >> that should be in it. Also the user/client keys. When he is  
> back I
> > >> can work with him to add all that stuff.
> > >
> > > Sure, let's do that. Or feel free to pull the XML out of SVN and
> > > start working on it. :)
> >
> > I just looked at it and PEP and some other XEPs and there are some
> > things I do not like. Maybe these XEPs need a small update for  
> this
> > use-case.
> >
> > 1. PEP says the last_item should only be send if the priority is  
> not
> >    negative. But all bots have a negative priority and will never  
> get
> >    the updates. Maybe an extra config option for PubSub/PEP: also  
> send
> >    to negative priority?
> 
> http://www.xmpp.org/extensions/xep-0060.html#filtered-notifications
> 
> No priority in PubSub.
> 
> In PEP:
> 
> "If a subscriber subscribed using a bare JID <localpart at domain.tld>  
> and
> a PEP service has appropriate presence information about the
> subscriber, the PEP service MUST send one notification to the full  
> JID
> (<localpart at domain.tld/resource> or <domain.tld/resource>) of each  
> of
> the subscriber's available resources that have specified  
> non-negative
> presence priority and included XEP-0115 information that indicates  
> an
> interest in the data format."
> 
> I believe that if some resource indicates an interest, it should get
> what it wants.
> 
> +1 for a change in the XEP
> 
> > 2. I like the fact that I get a notification when I start my  
> client
> >    when there is a new item (if it is configured that way). But I  
> also
> >    want to be notified when something was deleted (certificate
> >    revoked). What I would like to have is that I get a  
> notification
> >    from the server that "something has changed since I was last
> >    online" so I can get the whole tree of certificates.
> 
> You should not need to watch deleted item. Certificates are revoked,
> not deleted, revocation could be just easily announced as a new  
> item.
> 
> > Maybe move that discussion to the pubsub list? /me needs to  
> subscribe
> > to that list, too :)
> 
> Maybe, I'm not sure.

I'm sure. Copied. :-)

I (or someone) will report back with whatever it was that ended up  
being decided; in the meantime, assume that from a protocol  
perspective, we'll find a solution.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dmeyer at tzi.de  Tue Sep  2 05:22:27 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Tue, 02 Sep 2008 12:22:27 +0200
Subject: [Security] XEP Proposal: C2C Authentication using TLS,
	Version 0.0.2
In-Reply-To: <20080826183834.6c420192@tiger> (Pavel Simerda's message of "Tue\,
	26 Aug 2008 18\:38\:34 +0200")
References: <87bpzfu7f2.fsf@phex.sachmittel.de> <20080826183834.6c420192@tiger>
Message-ID: <8763peq23g.fsf@phex.sachmittel.de>

Pavel Simerda wrote:
> Looks better.
>
> On Tue, 26 Aug 2008 17:23:29 +0200
> Dirk Meyer <dmeyer at tzi.de> wrote:
>
>> Hi,
>> 
>> based on the feedback I updated my XEP proposal. 
>> 
>> ChangeLog:
>>   * Add extension probing
>>   * Add xmlsig namespace for keys
>>   * Change namespace to urn:xmpp:tmp:c2ctls
>>   * Add note about future TLS extensions like SAS
>> 
>> And I changed the name of the doc to match the new namespace. It can
>> be found at: http://www.tzi.de/~dmeyer/c2ctls.html

Any other comments? If not, I will add the missing stuff (e.g. schema)
and send it to Peter for the inbox.

Dirk

-- 
Hit any user to continue.

From winfried at tilanus.com  Tue Sep  2 08:18:09 2008
From: winfried at tilanus.com (Winfried Tilanus)
Date: Tue, 02 Sep 2008 15:18:09 +0200
Subject: [Security] End-to-end encryption with JavaScript client
Message-ID: <48BD3D11.6090200@tilanus.com>

Dirk Meyer dmeyer wrote:

Hi,

> It makes no
> sense to talk about e2e security when you receive your XMPP client
> from a server just before you use it.

Well, I have potential use for it: I am running chat-services for
social-psychological aid. My customers do trust me with software and
servers, they might or might not trust me with the content of the chats.

The work of some of my customers might be subject to laws on medical
secrecy, medical information protection or other (privacy) legislation.
Other customers have strict protocols on storage / not storing and who
should have access to the chats. Apart from this, different legislations
on things like wiretapping and handing over traffic to the police in
different countries might cause problems.

So e2e encryption on the following path: webclient <-> my server <->
(web)client can save me and my customers a lot of headaches: being
unable to know is usually the best for me.

This still leaves the question open whether it is feasible to make a
javascript client do XMPP over TLS over IBB over BOSH over HTTPS? ;-)

best wishes,

Winfried

-- 
http://www.tilanus.com
xmpp:winfried at jabber.xs4all.nl
tel. 015-3613996 / 06-23303960
fax. 015-3614406

From stpeter at stpeter.im  Tue Sep  2 14:24:22 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 02 Sep 2008 13:24:22 -0600
Subject: [Security] XEP Proposal: C2C Authentication using TLS,
 Version 0.0.2
In-Reply-To: <8763peq23g.fsf@phex.sachmittel.de>
References: <87bpzfu7f2.fsf@phex.sachmittel.de> <20080826183834.6c420192@tiger>
	<8763peq23g.fsf@phex.sachmittel.de>
Message-ID: <48BD92E6.5060303@stpeter.im>

Dirk Meyer wrote:

> Any other comments? If not, I will add the missing stuff (e.g. schema)
> and send it to Peter for the inbox.

If you send it now (no need for schema etc.) I can put it on the agenda 
for the XMPP Council meeting tomorrow. :)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080902/948f0955/attachment.bin 

From pavlix at pavlix.net  Tue Sep  2 14:39:45 2008
From: pavlix at pavlix.net (Pavel Simerda)
Date: Tue, 2 Sep 2008 21:39:45 +0200
Subject: [Security] XEP Proposal: C2C Authentication using TLS,
 Version 0.0.2
In-Reply-To: <8763peq23g.fsf@phex.sachmittel.de>
References: <87bpzfu7f2.fsf@phex.sachmittel.de> <20080826183834.6c420192@tiger>
	<8763peq23g.fsf@phex.sachmittel.de>
Message-ID: <20080902213945.41d4c8c5@tiger>

I'm sure there will be comments later but that's not a reason to hold
it :).

Pavel


On Tue, 02 Sep 2008 12:22:27 +0200
Dirk Meyer <dmeyer at tzi.de> wrote:

> Pavel Simerda wrote:
> > Looks better.
> >
> > On Tue, 26 Aug 2008 17:23:29 +0200
> > Dirk Meyer <dmeyer at tzi.de> wrote:
> >
> >> Hi,
> >> 
> >> based on the feedback I updated my XEP proposal. 
> >> 
> >> ChangeLog:
> >>   * Add extension probing
> >>   * Add xmlsig namespace for keys
> >>   * Change namespace to urn:xmpp:tmp:c2ctls
> >>   * Add note about future TLS extensions like SAS
> >> 
> >> And I changed the name of the doc to match the new namespace. It
> >> can be found at: http://www.tzi.de/~dmeyer/c2ctls.html
> 
> Any other comments? If not, I will add the missing stuff (e.g. schema)
> and send it to Peter for the inbox.
> 
> Dirk
> 


-- 

Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

From stpeter at stpeter.im  Tue Sep  2 16:22:38 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 02 Sep 2008 15:22:38 -0600
Subject: [Security] [Fwd: [Standards] Proposed XMPP Extension: C2C
 Authentication using TLS]
Message-ID: <48BDAE9E.8050305@stpeter.im>

FYI.

-------- Original Message --------
From: XMPP Extensions Editor <editor at xmpp.org>
To: standards at xmpp.org
Date: Tue, 02 Sep 2008 16:19:51 -0500
Subject: [Standards] Proposed XMPP Extension: C2C Authentication using TLS

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: C2C Authentication using TLS

Abstract: This document describes how to negotiate TLS extensions when 
using TLS for end-to-end XML streams between two clients. It covers 
X.509 certificates with an without CA, the use of OpenPGP, Shared Remote 
Passwords (SRP) and how to use one extension to bootstrap a trust 
relationship.

URL: http://www.xmpp.org/extensions/inbox/c2ctls.html

The XMPP Council will decide at its next meeting whether to accept this 
proposal as an official XEP.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080902/178139d0/attachment.bin 

From stpeter at stpeter.im  Wed Sep  3 21:13:38 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 03 Sep 2008 20:13:38 -0600
Subject: [Security] Perspectives: Improving SSH-style Host
 Authentication with Multi-Path Probing
In-Reply-To: <9235.1220341850.474535@peirce.dave.cridland.net>
References: <87prnvuc4c.fsf@phex.sachmittel.de>	<FB24EF2D-EA05-475F-8D75-7B5938CF68E6@simplicidade.org>	<874p54ruy4.fsf@phex.sachmittel.de>	<B8CAF6B0-0F64-4D02-80B0-4A5B95BDC854@simplicidade.org>	<3307.1220010183.085980@peirce.dave.cridland.net>	<10B3824F-0BDD-46F7-933B-9C3C9A330C01@simplicidade.org>	<87od3b4qzk.fsf@phex.sachmittel.de>
	<48BAC22D.9060102@stpeter.im>	<87bpz92f8s.fsf@phex.sachmittel.de>
	<20080902001308.373725f6@tiger>
	<9235.1220341850.474535@peirce.dave.cridland.net>
Message-ID: <48BF4452.40208@stpeter.im>

Dave Cridland wrote:
> On Mon Sep  1 23:13:08 2008, Pavel Simerda wrote:
>> On Sun, 31 Aug 2008 20:47:47 +0200
>> Dirk Meyer <dmeyer at tzi.de> wrote:
>>
>> > Peter Saint-Andre wrote:
>> > > Dirk Meyer wrote:
>> > >> Peter wants to give XEP-0189 more love, I guess this is something
>> > >> that should be in it. Also the user/client keys. When he is back I
>> > >> can work with him to add all that stuff.
>> > >
>> > > Sure, let's do that. Or feel free to pull the XML out of SVN and
>> > > start working on it. :)
>> >
>> > I just looked at it and PEP and some other XEPs and there are some
>> > things I do not like. Maybe these XEPs need a small update for this
>> > use-case.
>> >
>> > 1. PEP says the last_item should only be send if the priority is not
>> >    negative. But all bots have a negative priority and will never get
>> >    the updates. Maybe an extra config option for PubSub/PEP: also send
>> >    to negative priority?
>>
>> http://www.xmpp.org/extensions/xep-0060.html#filtered-notifications
>>
>> No priority in PubSub.
>>
>> In PEP:
>>
>> "If a subscriber subscribed using a bare JID <localpart at domain.tld> and
>> a PEP service has appropriate presence information about the
>> subscriber, the PEP service MUST send one notification to the full JID
>> (<localpart at domain.tld/resource> or <domain.tld/resource>) of each of
>> the subscriber's available resources that have specified non-negative
>> presence priority and included XEP-0115 information that indicates an
>> interest in the data format."
>>
>> I believe that if some resource indicates an interest, it should get
>> what it wants.
>>
>> +1 for a change in the XEP
>>
>> > 2. I like the fact that I get a notification when I start my client
>> >    when there is a new item (if it is configured that way). But I also
>> >    want to be notified when something was deleted (certificate
>> >    revoked). What I would like to have is that I get a notification
>> >    from the server that "something has changed since I was last
>> >    online" so I can get the whole tree of certificates.
>>
>> You should not need to watch deleted item. Certificates are revoked,
>> not deleted, revocation could be just easily announced as a new item.
>>
>> > Maybe move that discussion to the pubsub list? /me needs to subscribe
>> > to that list, too :)
>>
>> Maybe, I'm not sure.
> 
> I'm sure. Copied. :-)
> 
> I (or someone) will report back with whatever it was that ended up being 
> decided; in the meantime, assume that from a protocol perspective, we'll 
> find a solution.

I provisionally modified XEP-0163 to remove the prohibition on sending 
to negative resources. The next Council will need to approve that change 
because XEP-0163 has a status of Draft. I assume that the incoming 
Council Chair will handle that somehow. :)

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080903/d203acb0/attachment.bin 

From stpeter at stpeter.im  Wed Sep  3 21:13:33 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 03 Sep 2008 20:13:33 -0600
Subject: [Security] Perspectives: Improving SSH-style Host
 Authentication with Multi-Path Probing
In-Reply-To: <20080902001308.373725f6@tiger>
References: <87prnvuc4c.fsf@phex.sachmittel.de>	<FB24EF2D-EA05-475F-8D75-7B5938CF68E6@simplicidade.org>	<874p54ruy4.fsf@phex.sachmittel.de>	<B8CAF6B0-0F64-4D02-80B0-4A5B95BDC854@simplicidade.org>	<3307.1220010183.085980@peirce.dave.cridland.net>	<10B3824F-0BDD-46F7-933B-9C3C9A330C01@simplicidade.org>	<87od3b4qzk.fsf@phex.sachmittel.de>
	<48BAC22D.9060102@stpeter.im>	<87bpz92f8s.fsf@phex.sachmittel.de>
	<20080902001308.373725f6@tiger>
Message-ID: <48BF444D.4040604@stpeter.im>

Pavel Simerda wrote:
> On Sun, 31 Aug 2008 20:47:47 +0200
> Dirk Meyer <dmeyer at tzi.de> wrote:
>
> You should not need to watch deleted item. Certificates are revoked,
> not deleted, revocation could be just easily announced as a new item.

I think revocation belongs in OCSP, no? Or is this user revocation of a 
client cert?

>> And something else I also added a note in my XEP proposal about the
>> TLS verification: how should keys look like. XEP-0189 now uses xmldsig
>> which IMHO is very complicated. People now how a keys look in PEM
>> format. Maybe just use this?

Please! I haven't gotten around to fixing XEP-0189 along those lines, so 
feel free to do so now that you have SVN access. :)

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080903/2bcdbd70/attachment.bin 

From dmeyer at tzi.de  Sat Sep  6 14:54:57 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Sat, 06 Sep 2008 21:54:57 +0200
Subject: [Security] XEP-0189 Update Proposal Part 1
Message-ID: <874p4tdp7y.fsf@phex.sachmittel.de>

Hi,

before updating the XML file I want to discuss changes to XEP-0189
Public Key Publishing here. This post/thread should be about keyinfo.

I want to replace KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig# to
something self-defined. xmlsig is very complicated and developers know
how to handle X.509 certificates in PEM format. There is also much
better support for that in SSL libraries. On the downside my proposal
is not so XMLish. This should also be used for XEP-0250.

Proposal:

<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
  <x509 fingerprint='571b23d99892f4566017426e92c377288ed6c983'>
    <certificate>
       MIICXDCCAcWgAwIBAgIJAKBfLqul2lj3MA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV
       BAMUHmRtZXllckBqYWJiZXIuY29tXDJmdGVzdGNsaWVudDAeFw0wODA5MDYxOTI0
       MjVaFw0wOTA5MDYxOTI0MjVaMCkxJzAlBgNVBAMUHmRtZXllckBqYWJiZXIuY29t
       XDJmdGVzdGNsaWVudDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwaRLyj7J
       /mmliYhjEwGnRGRs6gmcPaIywEK2QLFz6c3/RmRabYbIOE0iZ22D33TguSNQBWfd
       lweT3bBETUhd3yuCcqWO5Ptiq/6wulMlxVeV5mxwNP/IF94VPWj0jHbRJcU8ZhS4
       UnX6R5q6OSfBGdUU4mYKdiaHpgqTAO9eeqUCAwEAAaOBizCBiDAdBgNVHQ4EFgQU
       b8touIdFuXF5clv2I/S1aOOFdN4wWQYDVR0jBFIwUIAUb8touIdFuXF5clv2I/S1
       aOOFdN6hLaQrMCkxJzAlBgNVBAMUHmRtZXllckBqYWJiZXIuY29tXDJmdGVzdGNs
       aWVudIIJAKBfLqul2lj3MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEA
       pA5tI1J9Qpn3jSoQctFksRLb2H3A48R3rU8/qnarwE/AyOvth3k3ulLEmhJBT+0S
       mVb6WzrZEA/2plu7DhR8ylhuvJv6cAEIN+TPha3yzO2P8uoVZf7hdunOhMLl2Z6w
       xEfiGI5X9OsaMeFOQa+B2C3uUVAMLbVV7Rp/qQkai1Y=
    </certificate>
  </x509>
  <signature fingerprint='428b1358a286430f628da23fb33ddaf6e474f5c5'>
     oMt+lwgGms8Ep9zBZMWteAy+LD/hZ7VzO4IiS2e+eQbSoyIF2Lh2257jX9dUJgD8
     sr1XxMY7yYamorUY2SfzfBjKsvC4btAv7H4fCd6JEnH6PpkLifZ4Y5vZL7WAojqM
     wxLLCg420sVEuEJW56D/f+GWj+uvrQ/cAhKSx2mSY7o=
  </signature>    
</keyinfo>

Fingerprint is the fingerprint of the X.509 certificate. Evey SSL lib
should be able to provide this.

Certificate is the certificate in PEM format. If I understand it
correctly, the PEM format is the DER format encoded with Base64. The
BEGIN CERTIFICATE and END CERTIFACE stuff from PEM was removed.

The signature is created by calling the hash and sign function of my
TLS library on everything between <certificate> and </certificate>
without the whitespaces or line break. So, it is a signature of the
PEM encoded certificate. This signature was transformed to Base64
after signing.

The signature is optional and there can be more than one signature.
Besides the certificate and the signature the keyinfo may also contain
<revoked/> or <expired/>. In that case the key should not be used
anymore.

<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
  <x509 fingerprint='571b23d99892f4566017426e92c377288ed6c983'>
    <certificate>
      ...
    </certificate>
  </x509>
  <signature fingerprint='428b1358a286430f628da23fb33ddaf6e474f5c5'>
    ...
  </signature>    
  </revoked/>
</keyinfo>

Besides X.509 OpenPGP should also be supported. I had not looked into
an implementation but I guess it would look similar. The signature is
outside the x509 element to make it possible to sign OpenPGP keys with
the the private key of a X.509 certificate and the other way around.

I do not know how this list handles attachments so I put some test
code to http://files.sachmittel.de/xep-0189.py
This code contains the certificates and private keys used in this
example.


Dirk

-- 
'The Geek shall inherit the earth.' - Linus 5:5

From justin at affinix.com  Sat Sep  6 16:01:40 2008
From: justin at affinix.com (Justin Karneges)
Date: Sat, 6 Sep 2008 14:01:40 -0700
Subject: [Security] XEP-0189 Update Proposal Part 1
In-Reply-To: <874p4tdp7y.fsf@phex.sachmittel.de>
References: <874p4tdp7y.fsf@phex.sachmittel.de>
Message-ID: <200809061401.40724.justin@affinix.com>

On Saturday 06 September 2008 12:54:57 Dirk Meyer wrote:
> I want to replace KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig# to
> something self-defined. xmlsig is very complicated and developers know
> how to handle X.509 certificates in PEM format. There is also much
> better support for that in SSL libraries. On the downside my proposal
> is not so XMLish. This should also be used for XEP-0250.

I think it's fine to skip the W3C KeyInfo format.  It doesn't really buy us 
anything.

> Certificate is the certificate in PEM format. If I understand it
> correctly, the PEM format is the DER format encoded with Base64. The
> BEGIN CERTIFICATE and END CERTIFACE stuff from PEM was removed.

Right, PEM is just the DER format encoded in Base64 with linebreaks and 
header/footer.  If you're going to hack PEM apart, I'd suggest simply 
specifying the format here as DER encoded in Base64 without linebreaks.  
Forget PEM.

> Fingerprint is the fingerprint of the X.509 certificate. Evey SSL lib
> should be able to provide this.

There is no standard fingerprint process for X.509 like there is with OpenPGP.  
X.509 certificates are commonly hashed into MD5 or SHA1.  You should pick an 
algorithm type and mention it in the document, or you should allow arbitrary 
algorithms to be used (and specified in the XML somehow).

For those unaware, when you see MD5 and SHA1 fingerprint hashes of 
certificates, it is simply a hashing of the DER format.  Therefore, everyone 
should be capable of calculating fingerprints with any algorithm, even if 
your X.509 library doesn't offer a direct method for doing so.

>   <signature fingerprint='428b1358a286430f628da23fb33ddaf6e474f5c5'>
>      oMt+lwgGms8Ep9zBZMWteAy+LD/hZ7VzO4IiS2e+eQbSoyIF2Lh2257jX9dUJgD8
>      sr1XxMY7yYamorUY2SfzfBjKsvC4btAv7H4fCd6JEnH6PpkLifZ4Y5vZL7WAojqM
>      wxLLCg420sVEuEJW56D/f+GWj+uvrQ/cAhKSx2mSY7o=
>   </signature>
>
> The signature is created by calling the hash and sign function of my
> TLS library on everything between <certificate> and </certificate>
> without the whitespaces or line break. So, it is a signature of the
> PEM encoded certificate. This signature was transformed to Base64
> after signing.

You lost me here.  Who is creating this signature?  Is the certificate signing 
itself?  What's the 'fingerprint' in <signature> for in this case?  I admit I 
didn't read the whole discussion.  Maybe this is some Web-of-Trust stuff?

Also, if you're going to sign the certificate, you should sign the DER.  That 
format is already canonicalized, no need to specially treat the PEM first, 
and it would be more consistent with my earlier suggestion about DER usage.

> The signature is optional and there can be more than one signature.
> Besides the certificate and the signature the keyinfo may also contain
> <revoked/> or <expired/>. In that case the key should not be used
> anymore.

What is the purpose of <revoked/> and <expired/> here?  Without signatures, 
they can only act as hints to the receiver to perform real validity checks.  
But the receiver should be doing real validity checks all the time then 
anyway, so I don't see the value in these hints.

-Justin

From dmeyer at tzi.de  Sat Sep  6 16:21:25 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Sat, 06 Sep 2008 23:21:25 +0200
Subject: [Security] XEP-0189 Update Proposal Part 1
In-Reply-To: <200809061401.40724.justin@affinix.com> (Justin Karneges's
	message of "Sat\, 6 Sep 2008 14\:01\:40 -0700")
References: <874p4tdp7y.fsf@phex.sachmittel.de>
	<200809061401.40724.justin@affinix.com>
Message-ID: <87y725c6ne.fsf@phex.sachmittel.de>

Justin Karneges wrote:
> Right, PEM is just the DER format encoded in Base64 with linebreaks and 
> header/footer.  If you're going to hack PEM apart, I'd suggest simply 
> specifying the format here as DER encoded in Base64 without linebreaks.  
> Forget PEM.

OK

>> Fingerprint is the fingerprint of the X.509 certificate. Evey SSL lib
>> should be able to provide this.
>
> There is no standard fingerprint process for X.509 like there is with OpenPGP.  
> X.509 certificates are commonly hashed into MD5 or SHA1.  You should pick an 
> algorithm type and mention it in the document, or you should allow arbitrary 
> algorithms to be used (and specified in the XML somehow).

Oh, I did not know that. In that case, yes, I need to add the hash
algorithm somewhere. What about signing stuff? It also uses a hash. A
quick look at the source code of tlslite looks like that the algorithm
is encoded in the signature. Am I right?

> For those unaware, when you see MD5 and SHA1 fingerprint hashes of 
> certificates, it is simply a hashing of the DER format.  Therefore, everyone 
> should be capable of calculating fingerprints with any algorithm, even if 
> your X.509 library doesn't offer a direct method for doing so.
>
>>   <signature fingerprint='428b1358a286430f628da23fb33ddaf6e474f5c5'>
>>      oMt+lwgGms8Ep9zBZMWteAy+LD/hZ7VzO4IiS2e+eQbSoyIF2Lh2257jX9dUJgD8
>>      sr1XxMY7yYamorUY2SfzfBjKsvC4btAv7H4fCd6JEnH6PpkLifZ4Y5vZL7WAojqM
>>      wxLLCg420sVEuEJW56D/f+GWj+uvrQ/cAhKSx2mSY7o=
>>   </signature>
>>
>> The signature is created by calling the hash and sign function of my
>> TLS library on everything between <certificate> and </certificate>
>> without the whitespaces or line break. So, it is a signature of the
>> PEM encoded certificate. This signature was transformed to Base64
>> after signing.
>
> You lost me here.  Who is creating this signature?  Is the certificate signing 
> itself?  What's the 'fingerprint' in <signature> for in this case?  I admit I 
> didn't read the whole discussion.  Maybe this is some Web-of-Trust stuff?

Yes. The idea was to have clients with a different certificate. The
client key was signed by a user key. This is important for bot
communication. There is no CA and I need a way to mark my bot
certificates as belonging-to-me.

> Also, if you're going to sign the certificate, you should sign the DER.  That 
> format is already canonicalized, no need to specially treat the PEM first, 
> and it would be more consistent with my earlier suggestion about DER usage.

You mean sign the binary data, not the Base64 one. I thought about
that, too, but it looked nicer to sign the stuff that was transmitted
over XMPP. But it is ok to sign the DER certificate, that is why I
wanted comments :)

>> The signature is optional and there can be more than one signature.
>> Besides the certificate and the signature the keyinfo may also contain
>> <revoked/> or <expired/>. In that case the key should not be used
>> anymore.
>
> What is the purpose of <revoked/> and <expired/> here?  Without signatures, 
> they can only act as hints to the receiver to perform real validity checks.  
> But the receiver should be doing real validity checks all the time then 
> anyway, so I don't see the value in these hints.

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 basic idea is also to use these keys for SASL-External later to
provide a login for clients without giving away the password. In that
case the XMPP server MUST know if a certificate is valid and allowed
to be used for login.


Dirk

-- 
Due to financial problems, the light at the end of
the tunnel will be shut down until further notice.

From justin at affinix.com  Sat Sep  6 17:31:25 2008
From: justin at affinix.com (Justin Karneges)
Date: Sat, 6 Sep 2008 15:31:25 -0700
Subject: [Security] XEP-0189 Update Proposal Part 1
In-Reply-To: <87y725c6ne.fsf@phex.sachmittel.de>
References: <874p4tdp7y.fsf@phex.sachmittel.de>
	<200809061401.40724.justin@affinix.com>
	<87y725c6ne.fsf@phex.sachmittel.de>
Message-ID: <200809061531.25780.justin@affinix.com>

On Saturday 06 September 2008 14:21:25 Dirk Meyer wrote:
> What about signing stuff? It also uses a hash.

There is no universal signature format for X.509, as far as I know.  The 
closest I can think of would be a Cryptographic Message Synax (PKCS#7) 
signature, but it seems doubtful that a library called 'tlslite' would be 
supporting CMS.

Most likely, tlslite is outputting a key-specific format.  For example, it 
could be using EMSA1 (for DSA) or EMSA3 (for RSA).  Both of these formats 
allow for different hash types to be used.

> 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 
used.

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.

> > You lost me here.  Who is creating this signature?  Is the certificate
> > signing itself?  What's the 'fingerprint' in <signature> for in this
> > case?  I admit I didn't read the whole discussion.  Maybe this is some
> > Web-of-Trust stuff?
>
> Yes.

So the fingerprint in the <signature> is the fingerprint of the one doing the 
signing (and not the fingerprint of the signature itself, that's what had me 
partly confused..).

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 
place?

> 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.

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.

-Justin

From dmeyer at tzi.de  Sun Sep  7 02:51:43 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Sun, 07 Sep 2008 09:51:43 +0200
Subject: [Security] XEP-0189 Update Proposal Part 1
In-Reply-To: <200809061531.25780.justin@affinix.com> (Justin Karneges's
	message of "Sat\, 6 Sep 2008 15\:31\:25 -0700")
References: <874p4tdp7y.fsf@phex.sachmittel.de>
	<200809061401.40724.justin@affinix.com>
	<87y725c6ne.fsf@phex.sachmittel.de>
	<200809061531.25780.justin@affinix.com>
Message-ID: <87sksccs1c.fsf@phex.sachmittel.de>

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 
> used.

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'>
|   BASE64
| </signature>

> 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 
> place?

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
anyway.

> 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
<revoke/> again.

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.


Dirk

-- 
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
you back.

From dmeyer at tzi.de  Mon Sep  8 08:52:35 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Mon, 08 Sep 2008 15:52:35 +0200
Subject: [Security] XEP-0189 Update Proposal Part 1
In-Reply-To: <874p4tdp7y.fsf@phex.sachmittel.de> (Dirk Meyer's message of
	"Sat\, 06 Sep 2008 21\:54\:57 +0200")
References: <874p4tdp7y.fsf@phex.sachmittel.de>
Message-ID: <87y7222198.fsf@phex.sachmittel.de>

Hi,

second version of my XEP-0189-using-ASCII proposal:

| <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
|   <name>unique identifier</name>
|   <x509cert>|<pgpdata>
|      ...
|   </x509cert>|</pgpdata>
|   <signature>
|     <issuer jid='optional'>unique identifier of issuer</issuer>
|     <value method='RSA-SHA1'>
|     </value>
|   </signature>
| </keyinfo>

Name is a unique name, a.k.a. fingerprint of the public key. For
OpenPGP this is the fingerprint defined by OpenPGP. For X.509 without
a standard fingerprint mechanisms this is the SHA1 value in hex of the
certificate. The name is used to search for a key and can be used as
reference in XEP-0250. The name is case-insentive but should be
written in lower case to allow PEP searching.

Next is the key information, X.509 certificate or OpenPGP public
key. For X.509 this is the certificate in DER format Base64 encoded.

| <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
|   <name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
|   <x509cert>
|     MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV
|     BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV
|     BAMTA2ZvbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0DPcfeJzKWLGE22p
|     RMINLKr+CxqozF14DqkXkLUwGzTqYRi49yK6aebZ9ssFspTTjqa2uNpw1U32748t
|     qU6bpACWHbcC+eZ/hm5KymXBhL3Vjfb/dW0xrtxjI9JRFgrgWAyxndlNZUpN2s3D
|     hKDfVgpPSx/Zp8d/ubbARxqZZZkCAwEAAaNvMG0wHQYDVR0OBBYEFJWwFqmSRGcx
|     YXmQfdF+XBWkeML4MD4GA1UdIwQ3MDWAFJWwFqmSRGcxYXmQfdF+XBWkeML4oRKk
|     EDAOMQwwCgYDVQQDEwNmb2+CCQC4VNCHesccEDAMBgNVHRMEBTADAQH/MA0GCSqG
|     SIb3DQEBBQUAA4GBAIhlUeGZ0d0msNVxYWAXg2lRsJt9INHJQTCJMmoUeTtaRjyp
|     ffJtuopguNNBDn+MjrEp2/+zLNMahDYLXaTVmBf6zvY0hzB9Ih0kNTh23Fb5j+yK
|     QChPXQUo0EGCaODWhfhKRNdseUozfNWOz9iTgMGw8eYNLllQRL//iAOfOr/8
|   </x509cert>
| </keyinfo>

For OpenPGP it is the public key, like X.509 it is the binary output
(default, not -a) and printed using Base64 encoding.

| <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
|   <name>89d099a3428481cc63fe3fa44e7df2d002b4ce44</name>
|   <pgpdata>
|     mQGiBDsKPy8RBACG1vVC8+5jMbtr8YUSfL2ciIu/Zb7/dDhwFd4iFlH7BIEt3RjR
|     wmiCUw/pcL8LHav7L2L4/Yxm8peJxyK0c11tP5Mq8kG3v55BSkZzn3fwKilEYG1c
|     rkOPWMEHds3c8kLDn+WNyxrSpw10EyJSsXc0edBdl7eLHiNQsCNmPpZhvwCg8uCQ
|     ...
|     HDU4Qg9lslDyfa2pHqkweHvC/LmIxrZeCSxOgSMLV8bqbbra1n3F4vdqgc8VP8I2
|     o9wBSf3HMohGBBgRAgAGBQI7Cj82AAoJEE598tACtM5EuWIAn0tHJF+Bk7pPAngp
|     hFOdFgS8UBSAAJ9ZPviS2XDzrWRpiyKV+hDqO/WTHA==
|   </pgpdata>
| </keyinfo>

Last the signature. It is needed to sign one key with another. If
someone already has my X.509 key he can use that to verify my
OpenPGP key. Bots could have X.509 client keys signed by a user key.

| <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
|   <name>571b23d99892f4566017426e92c377288ed6c983</name>
|   <x509cert>
|     MIICXDCCAcWgAwIBAgIJAKBfLqul2lj3MA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV
|     BAMUHmRtZXllckBqYWJiZXIuY29tXDJmdGVzdGNsaWVudDAeFw0wODA5MDYxOTI0
|     MjVaFw0wOTA5MDYxOTI0MjVaMCkxJzAlBgNVBAMUHmRtZXllckBqYWJiZXIuY29t
|     XDJmdGVzdGNsaWVudDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwaRLyj7J
|     /mmliYhjEwGnRGRs6gmcPaIywEK2QLFz6c3/RmRabYbIOE0iZ22D33TguSNQBWfd
|     lweT3bBETUhd3yuCcqWO5Ptiq/6wulMlxVeV5mxwNP/IF94VPWj0jHbRJcU8ZhS4
|     UnX6R5q6OSfBGdUU4mYKdiaHpgqTAO9eeqUCAwEAAaOBizCBiDAdBgNVHQ4EFgQU
|     b8touIdFuXF5clv2I/S1aOOFdN4wWQYDVR0jBFIwUIAUb8touIdFuXF5clv2I/S1
|     aOOFdN6hLaQrMCkxJzAlBgNVBAMUHmRtZXllckBqYWJiZXIuY29tXDJmdGVzdGNs
|     aWVudIIJAKBfLqul2lj3MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEA
|     pA5tI1J9Qpn3jSoQctFksRLb2H3A48R3rU8/qnarwE/AyOvth3k3ulLEmhJBT+0S
|     mVb6WzrZEA/2plu7DhR8ylhuvJv6cAEIN+TPha3yzO2P8uoVZf7hdunOhMLl2Z6w
|     xEfiGI5X9OsaMeFOQa+B2C3uUVAMLbVV7Rp/qQkai1Y=
|   </x509cert>
|   <signature>
|     <issuer>428b1358a286430f628da23fb33ddaf6e474f5c5</issuer>
|     <value method='RSA-SHA1'>
|       E3q/UkjRR3zcZMcIIoE2sSVKUATl26zyzO1Pmoe96p8apW91c3a0KqkQp1ZMBqXX
|       +e2ImqQ79CKv+9qzXitxx+V4EcniKN0ZsSR+9ZbfflxkOvmBa2rpq9hFE1NYyfuT
|       fsAZkRhAGlP7P5ELcvhqJ4WL6qBPYQU2NEnbVlcZSbA=
|     </value>
|   </signature>

Issuer defines the unique name of the key that was used to sign the
the key. Optional issuer can contain a jid of the issuer to make it
possible to find the issuer key. If it is the same user like in this
example this information is not needed. Note: the issuer in this
example is the X.509 from the first example.

Now the value of the signature. IIRC OpenPGP defines how to sign
something, X.509 does not. In that case we need to define the method
used for hash and sign. The only possible value right now is
'RSA-SHA1' (feel free to add more). See 6.4.2 of the xmldsig core or
RFC3110 section 3 how to compute this value.

The string to sign is everything in <x509cert> or <pgpdata> as binary
data. In the example above the steps are: get everything in
<x509cert>, remove the Base64 encoding, create SHA1 sum, add SHA
prefix, fill with padding data and sign. The used TLS lib should be
able to add the prefix and the padding without the user knowing.

For XEP-0250 we exchange the key info to know if we know the key. In
this case we can skip the signature and the key data, use XEP-0189 to
get this. We only need the identifier.

| <offer xmlns='urn:xmpp:tmp:c2ctls'>
|   <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
|     <name>571b23d99892f4566017426e92c377288ed6c983</name>
|   </keyinfo>
|   <srp/>
| </offer>

You have no way of knowning if the key is a X.509 certificate or
OpenPGP key (571b23d99892f4566017426e92c377288ed6c983). But that does
not matter, you can not verify a key you do not know. ;)

So when a client gets the offer above it can check the PEP of the peer
JID to get the key information if it needs it.



Dirk

-- 
Don't read everything you believe.

From justin at affinix.com  Mon Sep  8 10:23:15 2008
From: justin at affinix.com (Justin Karneges)
Date: Mon, 8 Sep 2008 08:23:15 -0700
Subject: [Security] XEP-0189 Update Proposal Part 1
In-Reply-To: <87y7222198.fsf@phex.sachmittel.de>
References: <874p4tdp7y.fsf@phex.sachmittel.de>
	<87y7222198.fsf@phex.sachmittel.de>
Message-ID: <200809080823.15613.justin@affinix.com>

On Monday 08 September 2008 06:52:35 Dirk Meyer wrote:
> second version of my XEP-0189-using-ASCII proposal:

Looks good to me.

From stpeter at stpeter.im  Mon Sep  8 10:25:19 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Mon, 08 Sep 2008 09:25:19 -0600
Subject: [Security] XEP-0189 Update Proposal Part 1
In-Reply-To: <200809080823.15613.justin@affinix.com>
References: <874p4tdp7y.fsf@phex.sachmittel.de>	<87y7222198.fsf@phex.sachmittel.de>
	<200809080823.15613.justin@affinix.com>
Message-ID: <48C543DF.5040106@stpeter.im>

Justin Karneges wrote:
> On Monday 08 September 2008 06:52:35 Dirk Meyer wrote:
>> second version of my XEP-0189-using-ASCII proposal:
> 
> Looks good to me.

Me, too.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/security/attachments/20080908/2b2b00a7/attachment.bin 

From dmeyer at tzi.de  Tue Sep  9 13:39:23 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Tue, 09 Sep 2008 20:39:23 +0200
Subject: [Security] XEP-0189 Signatures
Message-ID: <873ak9xixw.fsf@phex.sachmittel.de>

Hi,

XEP-0189 is now updated to use ASCII and also supports to sign a key
with another. This is not only usefull for signing client keys with a
server key, it is also useful for signing a X.509 certificate with an
OpenPGP key. After some saerching I found no TLS lib for Python
supporting TLS with OpenPGP. But if I sign my X.509 certificate with
the OpenPGP key we can use OpenPGP to verify the X.509 certificate (I
guess this practice should be written down somewhere).

But we also support SRP (and there is at least one Python lib that can
do that). After SRP is used it would be great to exchange certificates
so we can skip the password stuff the next time. So let's say I
exchange X.509 certificates with Peter over a SRP secured link. Now
what? I can sign his certificate so all my clients know that I already
verified that certificate. But where to store it? There are two
choices: my PEP or his PEP.

My PEP: I could add external keys to my XEP-0189 PEP. This would be
very confusing because it is not my key. We would have to add a jid to
keyinfo:

| <keyinfo jid="stpeter...">
|   <name>his key fingerprint</name>
|   <signaure>
|     my signature
|   </signature>
| </keyinfo>

Pros:
- Only I have write access and can control it
- I can remove the signature later

Cons:
- Confusing, maybe we can add a second pubsub node just for external
  keys I signed.
- Peter can not track who signed his key. Since we do not re-invent a
  compex web-of-trust (we have OpenPGP for that) this may not be a
  problem.


His PEP: First of all, I have no write access. I have to send him the
signature and he has to add it to his tree. He just adds my signature
to the list of signatures

| <keyinfo>
|   <name>his key fingerprint</name>
|   <signaure>
|     Peter's OpenPGP signature
|   </signature>
|   <signaure>
|     my signature
|   </signature>
| </keyinfo>

Pros:
- Peter can control the signatures
- Others can use this as some kind of web-of-trust when they see my
  signature and trust me.

Cons:
- I can not remove a signature later, only Peter can (is this a
  problem?)
- Complex because I have to send the signature to a client of Peter
  and that client does the upload.


Comments? Other Ideas?


Dirk

-- 
If you choke a Smurf, what color does it turn?


From dmeyer at tzi.de  Tue Sep  9 13:51:43 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Tue, 09 Sep 2008 20:51:43 +0200
Subject: [Security] XEP-0189 and XEP-0178 Interaction
Message-ID: <87tzcpw3sw.fsf@phex.sachmittel.de>

Hi,

In the thread Thread 'Hosted solutions - client/user certs' started by
Johansson Olle E. the idea of client cert with SASL came up.

I want to use a new client. I do not trust that client for its
life-time. E.g. a mobile phone can get stolen. It would be nice if
this client can log into my account without having my password.
XEP-0178 defines SASL-EXTERNAL but it is unclear where the certificate
comes from.

Here a small idea how it could work:

1. I create a certificate with my new client

2. I upload a client certificate to the XEP-0189 pubsub node. Either
   with a different client or with the new one and it should not store
   the password I use for login.

3. The XMPP server has access to the pubsub node, in fact, the pubsub
   node is part of the server.

4. The client logs into the network using SASL-EXTERNAL and its
   certificate.

5. The server sees the certificate in my pubsub node and grands
   access.

6. The device gets stolen and I remove the certificate. The client can
   log in anymore.

This sounds strait forward to me but some stuff is important:

1. Once I remove a certificate and the client is still loged in, the
   server MUST terminate the stream or the bad client can add its
   certificate again.

2. Who is allowed to add a certificate? Right now all my clients
   are. Is this a problem if a client with certificate can add
   another? A bad client can add others before it gets
   disconnected. Again: is this a problem?

We could use the signature stuff again. Only clients signed with my
user key can log in. But that will make things a bit complicated for
server developer.

BTW, if a bad client removes all certificates except its own, you
still have control because you always have the password login.


Comments on that? And where to put it? XEP-0189? XEP-0178? A new XEP?
And a question for server developer: how complicated is it to add a
feature like this?


Dirk

-- 
My Other car is a beater (On the back of a beater).

From oej at edvina.net  Tue Sep  9 15:03:27 2008
From: oej at edvina.net (Johansson Olle E)
Date: Tue, 9 Sep 2008 22:03:27 +0200
Subject: [Security] XEP-0189 and XEP-0178 Interaction
In-Reply-To: <87tzcpw3sw.fsf@phex.sachmittel.de>
References: <87tzcpw3sw.fsf@phex.sachmittel.de>
Message-ID: <FF12DE4B-3209-45CA-835D-503932009BA6@edvina.net>


9 sep 2008 kl. 20.51 skrev Dirk Meyer:

> Hi,
>
> In the thread Thread 'Hosted solutions - client/user certs' started by
> Johansson Olle E. the idea of client cert with SASL came up.
>
> I want to use a new client. I do not trust that client for its
> life-time. E.g. a mobile phone can get stolen. It would be nice if
> this client can log into my account without having my password.
> XEP-0178 defines SASL-EXTERNAL but it is unclear where the certificate
> comes from.

I propose that you separate the public key, private key and the cert
to be able to discuss the logic here. The cert is just a signed wrapper
around the public key. The private key is a very important part.

My idea was to have a client ID and a user ID. The user ID was
allowed to delegate authority to clients by signing the client's
public key in a cert format with the CN being the clients full JID,
that is with a locked resource to prevent multiple logins.

Storing it with pubsub seems like a smart idea. The question
is how the "client" gets access to pubsub without authorization.
That's food for thought. You don't want to open up for DOS attacks.

Thinking about your original analogy with bluetooth or the
AppleTV synch authorization, a shared secret might work.

* The USER uploads a pin code to a pubsub node.
* The CLIENT uploads a CERT to a pubsub node which
    has an ID in the form of a PIN number.
* The User retrieves the cert request, signs it. This can
    be published in the open, as only the Client has the
    private key (hopefully).

It's late and I'm tired, but give it some thought

(or pick it apart in pieces while I sleep :-) )

/O

From dave at cridland.net  Tue Sep  9 15:04:42 2008
From: dave at cridland.net (Dave Cridland)
Date: Tue, 09 Sep 2008 21:04:42 +0100
Subject: [Security] XEP-0189 and XEP-0178 Interaction
In-Reply-To: <87tzcpw3sw.fsf@phex.sachmittel.de>
References: <87tzcpw3sw.fsf@phex.sachmittel.de>
Message-ID: <25359.1220990682.143439@peirce.dave.cridland.net>

On Tue Sep  9 19:51:43 2008, Dirk Meyer wrote:
> BTW, if a bad client removes all certificates except its own, you
> still have control because you always have the password login.

Clients might also be able to change the password... That's possible  
now with the right XEPs.

> Comments on that? And where to put it? XEP-0189? XEP-0178? A new  
> XEP?
> And a question for server developer: how complicated is it to add a
> feature like this?

I'm thoroughly against "special" pubsub nodes, because they  
complicate the processing of pubsub/PEP requests.

So I'd be inclined to have a provisioning <iq/>, which might  
(possibly optionally) publish internally to XEP-0189. It also then  
has the ability to refuse to provision the certificate.

As to how difficult this is - not very.

I've done "proper" CA-based X.509 authentication in our  
implementation, and that's moderately complex, but do-able.

Doing simple certificate comparison, on the other hand, is pretty  
easy, since you just load in an X.509 object and check for equality.  
I think I could implement this reasonably quickly.

But I don't think you want this. I think you want to have a user  
control a "mini-me" account for automata - so maybe they get a fixed  
resource, and low rights - no ability to change certificates,  
passwords, or even roster items - and that'scomparitively much harder  
to do.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From dmeyer at tzi.de  Wed Sep 10 04:24:03 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Wed, 10 Sep 2008 11:24:03 +0200
Subject: [Security] XEP-0189 and XEP-0178 Interaction
In-Reply-To: <FF12DE4B-3209-45CA-835D-503932009BA6@edvina.net> (Johansson Olle
	E.'s message of "Tue\, 9 Sep 2008 22\:03\:27 +0200")
References: <87tzcpw3sw.fsf@phex.sachmittel.de>
	<FF12DE4B-3209-45CA-835D-503932009BA6@edvina.net>
Message-ID: <87r67s5p70.fsf@phex.sachmittel.de>

Johansson Olle E wrote:
> 9 sep 2008 kl. 20.51 skrev Dirk Meyer:
>
>> Hi,
>>
>> In the thread Thread 'Hosted solutions - client/user certs' started by
>> Johansson Olle E. the idea of client cert with SASL came up.
>>
>> I want to use a new client. I do not trust that client for its
>> life-time. E.g. a mobile phone can get stolen. It would be nice if
>> this client can log into my account without having my password.
>> XEP-0178 defines SASL-EXTERNAL but it is unclear where the certificate
>> comes from.
>
> I propose that you separate the public key, private key and the cert
> to be able to discuss the logic here. The cert is just a signed wrapper
> around the public key. The private key is a very important part.
>
> My idea was to have a client ID and a user ID. The user ID was
> allowed to delegate authority to clients by signing the client's
> public key in a cert format with the CN being the clients full JID,
> that is with a locked resource to prevent multiple logins.

So I client ID is the full JID and each full JID MAY have it's own
private key and certificate. The ressource is encoded in the
certificate. The CN being the clients full JID is a problem because
AFAIK you can not use a slash in the CN.

> Storing it with pubsub seems like a smart idea. The question
> is how the "client" gets access to pubsub without authorization.
> That's food for thought. You don't want to open up for DOS attacks.
>
> Thinking about your original analogy with bluetooth or the
> AppleTV synch authorization, a shared secret might work.
>
> * The USER uploads a pin code to a pubsub node.
> * The CLIENT uploads a CERT to a pubsub node which
>    has an ID in the form of a PIN number.

How can the client do that without a way to log in into my account?
Maybe we can do something like iq-register together with tokens. This
is independed of PubSub right now and only a basic idea.

1. USER sends a temp. password and ressource name to the server. This
   information is passed to the new client (e.g. it is again the user
   wanting to use this client).

2. CLIENT logs in and presents the certificate during STARTTLS

3. Server presents the SASL feature AND a feature to use the temp
   password. E.g. it could use sha1(temp.password+ressource) in SASL.

4. CLIENTS sends temp password and ressource. After that the temp
   password is invalid and can never be used again.

5. Server checks ressource against ressource in the certificate and if
   the temp password matches. If it does it adds the client
   certificate as client to be used for login. E.g. it could auto-add
   it to the pubsub node or use something else which provides the user
   to check which certificates are in the system

For a new bot in the network link-local messaging can be used

1. CLIENT starts and has no idea about its JID, server, password. It
   creates a certificate with the ressource it wants to have.

2. CLIENT searches for other clients using mDNS and discovers
   someone. It opens a connection to USER.

3. They can not verify each other and use SRP (the password is in the
   handbook of the CLIENT or printed at the back)

4. USER requests certificate from CLIENT and uploads it to the server

5. CLIENT uses the bare JID from the peer it is talking to and its
   password to log in.

To prevent a bad client to add many other clients we could require the
password in the first step and/or store permissions if a ressource is
allowed to add others.


Dirk

-- 
Viewer discretion may be advised, but it's never really expected.

From dmeyer at tzi.de  Wed Sep 10 04:32:32 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Wed, 10 Sep 2008 11:32:32 +0200
Subject: [Security] XEP-0189 and XEP-0178 Interaction
In-Reply-To: <25359.1220990682.143439@peirce.dave.cridland.net> (Dave
	Cridland's message of "Tue\, 09 Sep 2008 21\:04\:42 +0100")
References: <87tzcpw3sw.fsf@phex.sachmittel.de>
	<25359.1220990682.143439@peirce.dave.cridland.net>
Message-ID: <87ljy05osv.fsf@phex.sachmittel.de>

Dave Cridland wrote:
> On Tue Sep  9 19:51:43 2008, Dirk Meyer wrote:
>> BTW, if a bad client removes all certificates except its own, you
>> still have control because you always have the password login.
>
> Clients might also be able to change the password... That's possible
> now with the right XEPs.

It is? Can you give me a pointer in the right direction? IMHO to
change the password you should present the old one and that is
something a certificate-login-based client can not do.

>> Comments on that? And where to put it? XEP-0189? XEP-0178? A new
>> XEP?
>
> I'm thoroughly against "special" pubsub nodes, because they
> complicate the processing of pubsub/PEP requests.

It was only an idea. What do others think?

> But I don't think you want this. I think you want to have a user
> control a "mini-me" account for automata - so maybe they get a fixed
> resource, and low rights - no ability to change certificates,
> passwords, or even roster items - and that'scomparitively much harder
> to do.

Fixed resource could be easy if the resource is in the certificate.
Not to change passwords is also simple if you need the old password to
change it. But not to change roster items or add new clients will be
much harder. It would require some sort of config on the server for
each resource.

Stolen from PubSub:

<configure xmlns='xmpp:tmp:resource' resource'foo'>
  <x xmlns='jabber:x:data' type='submit'>
    <field var='FORM_TYPE' type='hidden'>
      <value>xmpp:tmp:resource#config</value>
    </field>
    <field var='resource#add_clients>
      <value>0</value>
    </field>
    <field var='resource#change_roster>
      <value>1</value>
    </field>
  </x>
</configure>

But that will require much additional login in the server.


Dirk

-- 
Someday I'll find that peer and reset his connection!

From oej at edvina.net  Wed Sep 10 05:11:21 2008
From: oej at edvina.net (Johansson Olle E)
Date: Wed, 10 Sep 2008 12:11:21 +0200
Subject: [Security] XEP-0189 and XEP-0178 Interaction
In-Reply-To: <87r67s5p70.fsf@phex.sachmittel.de>
References: <87tzcpw3sw.fsf@phex.sachmittel.de>
	<FF12DE4B-3209-45CA-835D-503932009BA6@edvina.net>
	<87r67s5p70.fsf@phex.sachmittel.de>
Message-ID: <58FC22BB-92D1-4C17-BDB8-9204704B889A@edvina.net>


10 sep 2008 kl. 11.24 skrev Dirk Meyer:

> Johansson Olle E wrote:
>> 9 sep 2008 kl. 20.51 skrev Dirk Meyer:
>>
>>> Hi,
>>>
>>> In the thread Thread 'Hosted solutions - client/user certs'  
>>> started by
>>> Johansson Olle E. the idea of client cert with SASL came up.
>>>
>>> I want to use a new client. I do not trust that client for its
>>> life-time. E.g. a mobile phone can get stolen. It would be nice if
>>> this client can log into my account without having my password.
>>> XEP-0178 defines SASL-EXTERNAL but it is unclear where the  
>>> certificate
>>> comes from.
>>
>> I propose that you separate the public key, private key and the cert
>> to be able to discuss the logic here. The cert is just a signed  
>> wrapper
>> around the public key. The private key is a very important part.
>>
>> My idea was to have a client ID and a user ID. The user ID was
>> allowed to delegate authority to clients by signing the client's
>> public key in a cert format with the CN being the clients full JID,
>> that is with a locked resource to prevent multiple logins.
>
> So I client ID is the full JID and each full JID MAY have it's own
> private key and certificate. The ressource is encoded in the
> certificate. The CN being the clients full JID is a problem because
> AFAIK you can not use a slash in the CN.
Hmm. Need to check that. Someone?

>
>
>> Storing it with pubsub seems like a smart idea. The question
>> is how the "client" gets access to pubsub without authorization.
>> That's food for thought. You don't want to open up for DOS attacks.
>>
>> Thinking about your original analogy with bluetooth or the
>> AppleTV synch authorization, a shared secret might work.
>>
>> * The USER uploads a pin code to a pubsub node.
>> * The CLIENT uploads a CERT to a pubsub node which
>>   has an ID in the form of a PIN number.
>
> How can the client do that without a way to log in into my account?

Well, my proposal was late-night security-by-obscurity. Only the
client would know the "pin code" that is the address of the pubsub
node - that would remain open for two minutes or something.

A better solution is propably something we all want :-)

/O


From adsxy.3fm6wt at no-mx.jabberforum.org  Fri Sep 12 02:52:08 2008
From: adsxy.3fm6wt at no-mx.jabberforum.org (adsxy)
Date: Fri, 12 Sep 2008 09:52:08 +0200
Subject: [Security] Why Choose Qoodaa to Transfer Files
Message-ID: <adsxy.3fm6wt@no-mx.jabberforum.org>


Qoodaa is one of the fatest software to transfer large files across the
world. It could send your files to all over the world, such as
Europe&#12289;America&#12289;Japanese,etc.And it's a good choice to
choose Qoodaa to transfer large files.
1&#12289;Its speed is faster than any other software to transfer large
files.
2&#12289;The uploaded files can be downloaded by multi-users for many
times. You only need to upload it for one time, and all the users from
all over the world can download it.
3&#12289;Resume broken/disconnected upload &download: If the network
interrupts in the process of files uploading or downloading, it can
automatically upload or download afer the network connected.
4&#12289;Flexible function. The uploaded files are stored by default
for 30 days, as long as you are a premium user, you can store your files
as long as you want. 
5 &#12289;It can download files quickly through downloading links.
You can send the file link by email,MSN,or even by telephone which is
quite convinient. in a word, it is time-saver and with high efficiency.

6&#12289;Competitive Price: You only need pay 3$ to send your files as
large as 1G to every corner of the world, but it costs $30 by mail.
What are you waiting for? Please go to http://www.qoodaa.com to
experience the surprise it brings to you.


-- 
adsxy
------------------------------------------------------------------------
adsxy's Profile: http://www.jabberforum.org/member.php?userid=17263
View this thread: http://www.jabberforum.org/showthread.php?t=758