Re: [Standards] rfc3920bis: proposed certificate text

[Peter Saint-Andre]

On 06/03/2008 9:31 PM, Justin Karneges wrote:
> On Tuesday 03 June 2008 9:58 am, Peter Saint-Andre wrote:
>> 15.2.  Certificates
>>
>>Channel encryption of an XML stream using Transport Layer Security as
>>described under Section 6, and in some cases also authentication as
>>described under Section 7, is commonly based on a digital certificate
>>presented by the receiving entity (or, in the case of mutual
>>authentication, both the receiving entity and the initiating entity).
>>This section describes best practices regarding the generation of
>>digital certificates to be presented by XMPP entities and the
>>verification of digital certificates presented by XMPP entities.
>>
>> 15.2.1.  Certificate Generation
>>
>> 15.2.1.1.  Server Certificates
>>
>>In a digital certificate to be presented by an XMPP server or service
>>(i.e., a SERVER CERTIFICATE), it is RECOMMENDED for the certificate
>>to include one or more JIDs (i.e., domain identifiers) associated
>>with domains serviced at the server.  The representations described
>>in the following sections are RECOMMENDED.  These representations are
>>described in preference order.
>>
>> 15.2.1.1.1.  Service Name
>>
>>A server's domain identifier SHOULD be represented as a service name,
>>i.e., as an otherName field of type "id-on-dnsSRV" as specified in
>>[X509-SRV].
>>
>> 15.2.1.1.2.  DNS Name
>>
>>A server's domain identifier SHOULD be represented as a DNS name,
>>i.e., as a subjectAltName extension of type dNSName.
>>
>>The DNS name MAY contain the wildcard character '*'.  The wildcard
>>character applies only to the left-most domain name component or
>>component fragment and match any single component or component
>>fragment.  For instance, a DNS name of *.example.com matches
>>foo.example.com but not bar.foo.example.com or example.com itself;
>>similarly, a DNS name of im*.example.net matches im1.example.net and
>>im2.example.net but not chat.example.net or example.net itself.
>>
>> 15.2.1.1.3.  XMPP OID
>>
>>A server's domain identifier MAY be represented as an XMPP OID, i.e.,
>>as a UTF8String within an otherName entity inside the subjectAltName,
>>using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under
>>Section 15.2.1.3.  In server certificates, this representation is
>>included for the sake of backward-compatibility.
>>
>> 15.2.1.1.4.  Common Name
>>
>>A server's domain identifier MUST NOT be represented as a Common
>>Name; instead, the Common Name field MUST be reserved for
>>representation of a human-friendly name.
> 
> I don't think we need to make this assertion.  There's no mention of Common 
> Name in any of the validation rules that follow, so that would mean the field 
> is effectively unused for XMPP anyway.
> 
> If for some reason we want to help encourage proper use of the Common Name 
> field, let's go with "SHOULD NOT".  I think "MUST NOT" is too ambitious here, 
> when many servers (or CAs for that matter) still actively populate the Common 
> Name with the domain and it would be too much to consider all of those certs 
> non-compliant for XMPP.

Works for me. Changed.

>> 15.2.1.1.5.  Examples
>>
>>For our first (relatively simple) example, consider a company called
>>"Example Products, Inc."  It hosts an XMPP service at
>>"im.example.com" (i.e., user addresses at the service are of the form
>>"[EMAIL PROTECTED]"), and SRV lookups for the xmpp-client and xmpp-
>>server services at "im.example.com" yield one machine, called
>>"x.example.com", as follows:
>>
>>_xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com
>>_xmpp-server._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com

Copy and paste error. Fixed.

> I'd probably make this example use 5269 for the server port, to avoid 
> potential distraction from the real topic.
> 
>>The certificate presented when connecting to x.example.com contains
>>the following representations:
>>
>>subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.im.example.com
>>subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.im.example.com
>>subjectAltName=dNSName:im.example.com
>>subjectAltName=otherName:id-on-xmppAddr;UTF8:im.example.com
>>CN=Example Products, Inc.
>>
>>For our second (more complex) example, consider an ISP called
>>"Example Internet Services".  It hosts an XMPP service at
>>"example.net" (i.e., user addresses at the service are of the form
>>"[EMAIL PROTECTED]"), but SRV lookups for the xmpp-client and xmpp-
>>server services at "example.net" yield two machines ("x1.example.net"
>>and "x2.example.net") as follows:
>>
>>_xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
>>_xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.
>>_xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
>>

Re: [Standards] rfc3920bis: proposed certificate text

[Justin Karneges]

On Tuesday 03 June 2008 9:58 am, Peter Saint-Andre wrote:
> 15.2.  Certificates
>
>Channel encryption of an XML stream using Transport Layer Security as
>described under Section 6, and in some cases also authentication as
>described under Section 7, is commonly based on a digital certificate
>presented by the receiving entity (or, in the case of mutual
>authentication, both the receiving entity and the initiating entity).
>This section describes best practices regarding the generation of
>digital certificates to be presented by XMPP entities and the
>verification of digital certificates presented by XMPP entities.
>
> 15.2.1.  Certificate Generation
>
> 15.2.1.1.  Server Certificates
>
>In a digital certificate to be presented by an XMPP server or service
>(i.e., a SERVER CERTIFICATE), it is RECOMMENDED for the certificate
>to include one or more JIDs (i.e., domain identifiers) associated
>with domains serviced at the server.  The representations described
>in the following sections are RECOMMENDED.  These representations are
>described in preference order.
>
> 15.2.1.1.1.  Service Name
>
>A server's domain identifier SHOULD be represented as a service name,
>i.e., as an otherName field of type "id-on-dnsSRV" as specified in
>[X509-SRV].
>
> 15.2.1.1.2.  DNS Name
>
>A server's domain identifier SHOULD be represented as a DNS name,
>i.e., as a subjectAltName extension of type dNSName.
>
>The DNS name MAY contain the wildcard character '*'.  The wildcard
>character applies only to the left-most domain name component or
>component fragment and match any single component or component
>fragment.  For instance, a DNS name of *.example.com matches
>foo.example.com but not bar.foo.example.com or example.com itself;
>similarly, a DNS name of im*.example.net matches im1.example.net and
>im2.example.net but not chat.example.net or example.net itself.
>
> 15.2.1.1.3.  XMPP OID
>
>A server's domain identifier MAY be represented as an XMPP OID, i.e.,
>as a UTF8String within an otherName entity inside the subjectAltName,
>using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under
>Section 15.2.1.3.  In server certificates, this representation is
>included for the sake of backward-compatibility.
>
> 15.2.1.1.4.  Common Name
>
>A server's domain identifier MUST NOT be represented as a Common
>Name; instead, the Common Name field MUST be reserved for
>representation of a human-friendly name.

I don't think we need to make this assertion.  There's no mention of Common 
Name in any of the validation rules that follow, so that would mean the field 
is effectively unused for XMPP anyway.

If for some reason we want to help encourage proper use of the Common Name 
field, let's go with "SHOULD NOT".  I think "MUST NOT" is too ambitious here, 
when many servers (or CAs for that matter) still actively populate the Common 
Name with the domain and it would be too much to consider all of those certs 
non-compliant for XMPP.

> 15.2.1.1.5.  Examples
>
>For our first (relatively simple) example, consider a company called
>"Example Products, Inc."  It hosts an XMPP service at
>"im.example.com" (i.e., user addresses at the service are of the form
>"[EMAIL PROTECTED]"), and SRV lookups for the xmpp-client and xmpp-
>server services at "im.example.com" yield one machine, called
>"x.example.com", as follows:
>
>_xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com
>_xmpp-server._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com

I'd probably make this example use 5269 for the server port, to avoid 
potential distraction from the real topic.

>The certificate presented when connecting to x.example.com contains
>the following representations:
>
>subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.im.example.com
>subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.im.example.com
>subjectAltName=dNSName:im.example.com
>subjectAltName=otherName:id-on-xmppAddr;UTF8:im.example.com
>CN=Example Products, Inc.
>
>For our second (more complex) example, consider an ISP called
>"Example Internet Services".  It hosts an XMPP service at
>"example.net" (i.e., user addresses at the service are of the form
>"[EMAIL PROTECTED]"), but SRV lookups for the xmpp-client and xmpp-
>server services at "example.net" yield two machines ("x1.example.net"
>and "x2.example.net") as follows:
>
>_xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
>_xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.
>_xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
>_xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.

5269.

>Example Internet Services also hosts chatrooms at chat.example.net,
>and provides SRV records for those services as well.  It 

Re: [Standards] XEP-107 and XEP-108: Empty Value?

[Peter Saint-Andre]

On 05/23/2008 7:26 AM, Florian Zeitz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
>> It seems rather messy to delete the node and then re-create it all the
>> time. For example, lots of geolocation services enable you to specify
>> certain locations that are private. So when you move to a private
>> location, you want to stop publishing temporarily. But you might start
>> publishing again 20 minutes later or whatever. So why delete the node
>> (along with all its subscriptions) only to re-create it so soon?
>>
>> Peter
>>
> 
> Agreed. Deleting and recreating nodes probably creates (server) overhead
> I didn't really think about. Probably retracting the node (which is what
> Miranda, Psi and Gajim SVN do) is equally bad and has the added penalty
> of not being required for PEP.
> On the other hand defining empty states (or a  element as Dave
> Cridland suggested) doesn't sound right to me either, because User
> Tune/Nickname/Mood/Activity/Geolocation/Weather/Clothing as I understand
> it mainly defines a generic XML format to express "things".
> Outside the context of PEP lack of information in this XML is useless.
> The XML just wouldn't be present in the first place. BUT in PEP this
> requires deleting/retracting the node...
> 
> Another thought: Delete nodes, BUT make sure it's a rare case.
> Normally, as you point out, people who published information will do it
> again. The node should only be deleted if they really don't want to
> publish any information.
> When this is the case is different for every "User *", but I think the
> XEPs can be defined in a way that it is a rare case that people don't
> want to publish any information.
> 
> So let's look at this per XEP:
> 
> User Tune:
> normally people will listen to music or not and publish the song or a
> stopped state accordingly. The case that people are secretly listening
> to a song is probably relatively rare.
> 
> User Mood:
> This has the problem that not every possible mood is present. Adding a
> "something else" option might be a solution here (Or is it valid to only
> send ? I think clients don't allow it...). I personally wouldn't
> publish my mood at all (maybe in rare cases) because I think it's to
> personal. People who decide to publish it will probably do it all the time.
> 
> User Activity:
> Same as User Mood IMHO. A "doing something else" state would help .
> 
> User Geolocation:
> Defining a  state would help. Admittedly this is very similar
> to providing no information at all which is what I didn't want to
> define, but IMHO this privacy statement is still a bit different from no
> information.
> 
> User Nickname:
> People who don't want a nickname any more will probably not want one for
> a longer period of time.
> 
> I think if this changes were made nodes wouldn't be deleted to often,
> but still could be if no information is to be published, in which case
> deleting the node is the "right thing" to do IMHO.

Those proposals are fine with me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] New XMPP Use Case: Private Media Networks

[Peter Saint-Andre]

On 05/20/2008 1:28 PM, Dirk Meyer wrote:
> Hi,
> 
> I wrote a first draft of a possible XMPP extension which opens new use
> cases for XMPP. But before I go into details, let me introduce
> myself: my name is Dirk Meyer and I work at the TZI which is part of
> the University of Bremen. My doctor thesis is about media networks and
> possible new use cases if all devices of a user can interact with each
> other.
> 
> Unlike a HTTP based approach like UPnP, XMPP provides a much better
> core for what I call a "Personal Media Network". My first (not
> finished) draft can be found at
> 
> http://www.tzi.de/~dmeyer/media-network.html

First, thanks for writing this.

A few comments...

You might want to make it clear that by "server" you don't mean "XMPP
server" and by "client" you don't mean "XMPP client".

In your architecture, is a "node" (1) <[EMAIL PROTECTED]> or (2)
<[EMAIL PROTECTED]/resource>? If (2), does each application have its
own certificate?

About authorization, you might want to check out XEP-0235.

About security, what about using something like XTLS?

http://www.xmpp.org/extensions/inbox/xtls.html

That needs a lot of work, but it seems similar to what you are proposing.

> Before finishing it and sending it to the XMPP council I want to ask on
> this list for some opinions about it. It clearly uses XMPP in a way
> XMPP was not indented to be used, but it could be the base for new use
> cases (examples of such use cases are in the document).

Well, HTTP is being used for things that Tim Berners-Lee never intended,
so who are we to complain about creative uses of XMPP? :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] New XMPP Use Case: Private Media Networks

[Peter Saint-Andre]

On 05/30/2008 12:12 PM, Dirk Meyer wrote:
> Dave Cridland wrote:
>> One thing that does immediately ring alarm bells for me, personally,
>> is that the design conflates several orthogonal aspects of
>> inter-device communication.  There's a number of reasons I don't
>> like this, in particular because if other protocols and/or profiles
>> want to use these, they'd have to reference your XEP piecewise,
>> which makes these new XEPs harder to follow.
> 
> After some thinking, I guess I will split my proposal into three XEPs:
> 
> 1. Service Provider including section 4. I will also add
>variable monitoring to it.
> 
> 2. Client-to-Client Communication including section 6. After reading
>some more XEPs, I guess jingle is the way to go to open the stream
>between clients. I will change that.
> 
> 3. Authorization Service will include sections 7 and 8.
> 
> Sections 3 and 5 will be moved to one of these three, I'm not sure
> now.
> 
> I would like to start with the first one, sending it to the XMPP
> council next week. One question: the doc says I should send it to
> http://www.xmpp.org/extensions/inbox/. But looking at that dir, I see
> only html files. Doesn't it make more sense to upload the xml file?
> What is the correct way to do this?

Please send the XML file to , or directly to me
off-list. :)

I'll try to comment on your proposal here soon.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Jingle: one RTP application type to bind them all?

[Peter Saint-Andre]

On 05/30/2008 1:45 PM, Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> On 05/29/2008 1:38 PM, Robert McQueen wrote:
>>> Peter Saint-Andre wrote:
>>> I think I'm in favour of this, given the two XEPs seem to be copies of
>>> each other. We could just have one RTP/AVP description XEP, with a media
>>> type field. 
>> Yes I looked into that a while back. For instance we might have this:
> 
> ...
> 
>> So while I think that including the media type as attributes of the
>>  element is helpful in some instances, it doesn't give you
>> everything you need in order to determine whether you want to accept the
>> negotiation or whatever.
> 
> Aiee! This seems like crazy over-generalisation to me. Every different
> content description markup will have its own way of describing what it
> wants to do (if necessary), especially when we do stuff like re-using
> existing namespaces like file transfer.
> 
> Why would you you want to say in two places you're doing audio, or say
> in one place you're doing audio, and somewhere else say you're doing it
> over RTP? Not to mention it would invoke yet another registry of
> namespaces/values/attributes we have to take care of.

Yeah ignore that ramble I sent.

> I was thinking of a direct analogy to the media field saying "audio" or
> "video" in your m-line in SDP. So like:
> 
> 
>   
> 
>   
>   
> 
> 
>   
> 
> 
> Then we'd just define some features to explain what media you supported,
> like:
> 
> urn:...:jingle-rtp#media-audio
> urn:...:jingle-rtp#media-video

Works for me.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Jingle: one RTP application type to bind them all?

[Peter Saint-Andre]

On 05/30/2008 1:24 PM, Robert McQueen wrote:
> Paul Witty wrote:
>  > I'm in favour of simplifying things down so that there's as much in
>> common between audio/video channels as possible.  Though the use of the
>> word "one" in the above paragraph seems to suggest a single RTP channel,
>> implying all media being received on a single UDP port.  This would be a
>> bad idea at least where doing Jingle <-> SIP gateways is concerned, as
>> SIP uses separate UDP streams for each content type, so the gateway
>> would have to inspect each packet incoming on the Jingle side to
>> determine the payload type to send it out on the correct port.
> 
> Yeah, I don't think Peter meant to say the same channel... :P 

Right, I used that term off-the-cuff.

> The idea
> is just using the same negotiation namespaces and XEP to describe all
> RTP media content, be it audio or video. 

Correct.

> We'd lose in so many ways by
> doing anything other than staying compatible with SDP here. It's just
> not a correct use of RTP to pretend that switching payload type is
> switching media type too.

Shall I take that as a vote for consolidating XEP-0167 and XEP-0180 into
one "Jingle-RTP" spec?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] MUC History clearing

[Peter Saint-Andre]

On 06/03/2008 1:06 PM, Boyd Fletcher wrote:
> So are we going to be able to do this soon?
> 
> if not we would like to see MUC Clearning added to the core XEP for MUC.

I realize you would like this, but IMHO it's a nice add-on feature and
not something core to the spec. I think it's time to declare XEP-0045
feature-complete and define these little additions in new ways.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Jingle gateways, Stanza Session Negotiation and Service Discovery

[Peter Saint-Andre]

Sorry for the slow reply.

On 04/23/2008 4:04 AM, Paul Witty wrote:
> Peter Saint-Andre wrote:
>> Paul Witty wrote:
>>  
>>> From what I can tell, XEP-0155 helps to get around this.  However, it
>>> would be nice to include the ability to not just share presence, but to
>>> also share service discovery information.
>>> 
>>
>> As an option in the XEP-0155 negotiation? That seems sensible. Does it
>> need to be a separate option or shall we assume that if you want to
>> share presence you're also willing to share service discovery data?
>> Probably it's best to make it explicit.
>>
>>   
> There needs to be a way to indicate that we are doing XEP-0155 in order
> to find presence and service discovery.  As it stands, all we can do is
> say that we may want to share presence, but the far end is under no
> obligation to do so.  While this makes sense for a text chat, if we want
> to start a Jingle session we can't do anything without presence and
> service information.  There should be a way that we say presence and
> service discovery (and perhaps Jingle) are required in this session, so
> that the client can reject/ignore the request immediately.

Well, I think realistically for seamless communication you would
register with a gateway and it would know your capabilities, so that it
could do the right thing in routing inbound calls from people who are
not on your roster.

> To make my life easier, something could be added to XEP-0166 saying that
> clients supporting Jingle should support XEP-0155, or even something
> similar to XEP-0155 but much lighter weight.

I'm all ears. :)

>>> I've not yet tried doing this; it may be that it's entirely the wrong
>>> way to go about it, so if anyone can suggest a better way, please speak
>>> up.  For example, I'd like it so that one person could have many
>>> different ways to be contacted e.g. H.323 endpoint, Jingle/XMPP client
>>> on their desktop, Jingle/XMPP client at home.  We can't know in advance
>>> what XMPP resource the user will have, so we want to just store the IP
>>> address of their H.323 endpoint (e.g. 1.2.3.4) and their XMPP ID, and
>>> then connect to whichever resource is currently available.
>>> 
>>
>> If you don't have any existing relationship with me and my server lets
>> you know what my resources are, I would consider that to be a leak of
>> private information. So I realize this is a pain, but sharing presence
>> and resource information with unknown entities is widely considered to
>> be a leak in the XMPP world. So we need to work around that, which we
>> can do with XEP-0155, presence subscriptions, RAP (XEP-0168), etc.
>>   
> I'm all for this, but I think that we should give the client the choice
> to allow incoming sessions from unknown clients, rather than having the
> server reject everything outright.

That makes sense in general, though people need to understand the risks
(and some services might forbid that outright, e.g. as Google Talk does
because it's trying to protect its users).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Jingle: multiple candidates per transport-info?

[Peter Saint-Andre]

On 05/29/2008 1:42 PM, Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> Olivier Crête also wondered why in Jingle ICE-UDP a transport-info
>> message is restricted to containing only one ICE candidate, rather than
>> allowing multiple candidates:
>>
>> http://mail.jabber.org/pipermail/standards/2008-April/018554.html
>>
>> Olivier pointed out that allowing a transport-info message to contain
>> multiple candidates would be more consistent with the SDP offer/answer
>> model, thus making it easier to write clients that support both Jingle
>> and SIP as well as gateways between Jingle and SIP. However, it is my
>> understanding that this approach would be inconsistent with the approach
>> taken by Google Talk as well as any existing Jingle implementations.
>> Therefore feedback would be appreciated regarding the implications of
>> such a change.
> 
> It's not very hard for us to support both - our media engine tells us
> when it's done gathering candidates so that we can generate SDP offers,
> so similarly, we can generate a "one-shot" all-candidate offer. And,
> processing several candidates received can easily be split up if necessary.
> 
> So I'd be in favour of making things more similar and allowing offers of
> all of the candidates, and offering the ability to trickle candidates
> (which I think the ICE RFC got rid of, but I've not checked recent
> drafts)

Yes IIRC that went away at some point.

> as an optimisation which may allow you to connect sooner, a la
> Google Talk.

In VoIP people seem to care a lot about connecting sooner. :)

If we don't allow this, then at least we may want to define how a
gateway should handle trickled candidates (wait x seconds and bundle them?).

> FWIW, our Jingle implementation only implements the Google Talk
> compatible transport at the moment anyway, so we can meet any reasonable
> XEP modifications. We've got a full ICE implementation but we've not
> connected it up with our XMPP signalling yet. Hopefully within a month
> or two so we can do some interop testing.

Coolio.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] XEP-0176 - Jingle ICE-UDP Security Issue

[Peter Saint-Andre]

On 06/03/2008 2:14 PM, Maiku wrote:
> In XEP-0176, Jingle using the ICE-UDP transport method, it says for
> the initiator to send out the transport candidates either as soon as
> getting the ACK from the session-initiate message or just as soon as
> sending the session-initiate message, but I can't seem to find any
> place that mentions where the responder's client would wait for the
> responder to actually click to accept the session. Where would this
> happen? Would the responder wait to send transport-info packets until
> the user actually accepts? If not, wouldn't that be a security issue,
> sending out your IP address to anyone who tries to start a session
> with you?

Maiku and I chatted about this via IM just now. I think it would make
sense for the client to have a configuration setting such as "it's OK to
share my personally identifying information (such as my network
location) with people who can see my presence" [yeah yeah yeah that's
long, shorten it as necessary!]. So if you share presence, your client
will ack the session-initiate, return a ringing message, and start
sending candidates. If you don't share presence, you would ack and send
ringing but not share candidates until the user accepts the negotiation.

Thoughts?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

[Standards] XEP-0176 - Jingle ICE-UDP Security Issue

[Maiku]

In XEP-0176, Jingle using the ICE-UDP transport method, it says for
the initiator to send out the transport candidates either as soon as
getting the ACK from the session-initiate message or just as soon as
sending the session-initiate message, but I can't seem to find any
place that mentions where the responder's client would wait for the
responder to actually click to accept the session. Where would this
happen? Would the responder wait to send transport-info packets until
the user actually accepts? If not, wouldn't that be a security issue,
sending out your IP address to anyone who tries to start a session
with you?

Re: [Standards] XEP-0167: Jingle Audio via RTP; Message order and content-accept

[Peter Saint-Andre]

On 04/26/2008 9:41 AM, Maiku wrote:
> I'm slightly confused about the order of the messages that are supposed to
> be sent when negotiating a Jingle audio session.
> 
> In section 5 of XEP-0167, it appears that the order is supposed to be
> "session-initiate", "content-accept", "session-accept". Later on in section
> 9, it instead uses the order "session-initiate", "session-info (ringing)",
> "transport-info", "content-replace", and finally "session-accept" (acks
> assumed).
> 
> Looking through the other Jingle XEPs, the section 9 order appears to be
> correct. What confuses me is in section 5, the line "If the responder wishes
> to accept the session, it MUST send a content-accept action to the
> initiator", but in several of the examples, in section 9, they don't even
> have a content-accept, and none of them are sent by the responder.
> 
> Could someone please clarify this for me?

I think I have not kept Section 5 in sync with Section 9. My bad. Will fix.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] MUC History clearing

[Boyd Fletcher]

So are we going to be able to do this soon?

if not we would like to see MUC Clearning added to the core XEP for MUC.

boyd



On 5/14/08 5:19 PM, "Peter Saint-Andre" <[EMAIL PROTECTED]> wrote:

> On 05/14/2008 11:04 AM, Gaston Dombiak wrote:
>> +1
>> 
>> BTW, besides defining in the new XEP the clear history command. Are you
>> planning to also define commands for things that currently exist in XEP-45?
>> Servers that currently support XEP-45 won't have to spend a lot of work if
>> they want to support the new XEP.
> 
> Yes we could define ad-hoc commands for things like kick and ban, it's
> just a different interface to the same features. But I haven't looked at
> that in detail yet.
> 
> And maybe at the same time we'll finally define some of the service-wide
> MUC admin features people have been asking for since 2002. :P
> 
> Peter

Re: [Standards] NEW: XEP-0243 (XMPP Server Compliance 2009)

[Dave Cridland]

On Tue Jun  3 18:11:37 2008, Peter Saint-Andre wrote:

On 05/29/2008 5:10 PM, Dave Cridland wrote:
> 1) I talked to Isode's marketing department, and the consensus   
was that

> having "Basic" and "Intermediate" doesn't make much sense. Having
> "Standard" and "Advanced" is likely to get more buy-in - nobody   
wants to

> call themselves Basic (It sounds like "Rubbish"), and Intermediate
> implies an Advanced somewhere. (The goal here would be that   
Standard is

> relatively easy for newcomers to get to, Advanced is where we want
> everyone to get to soon - inserting an Intermediate is okay   
later).


Ah yes it's all about marketing. :)

Does "standard" make it sound like anything else is "non-standard"?  
 How

about "core" and "advanced"?



Core-blimey!

Ahem.

I'll ask, but that sounds reasonable to me.


> 2) Also from our marketing dept: It's only a certification level   
if
> there's a certificate. Compliance levels are okay, even without   
formal

> compliance testing.

What exactly is a certificate? A piece of paper or a little icon   
that

you slap on your website or something else?


Paper was mentioned, and for some strange reason so was cake. I'm not  
 sure why. But the primary reason for certification would be a   
trustable brand - something that says something other than "Isode   
likes to say we meet this". In practise this would be a trademark   
held by the XSF and licensed as per this document.



We won't have formal compliance testing anytime soon I think, but   
if we

put some effort into the interop network then we can at least have
something stronger than mere self-reports if you can't be certified
without participating there.


That might work - we could introduce voting inside the interop   
network or something. But meanwhile, there is no certification   
procedure worth calling same.



> 3) In other news, I'm still not sure about In-Band Registration   
being
> required anywhere. It's not because it's hard to do, it's because  
 I
> don't think it's worth having a required feature that won't be   
needed
> nor used by the vast majority of deployments. I can see it's a   
good plan

> for public servers, of course.

Is it still in the client suites? I thought I had removed it from   
the

server suites.


I meant the server suites - having it required in the client suites   
is fine by me, actually, since it's useful to promote XMPP uptake.   
(Equally, server implementors wishing to target the public XMPP   
server market will probably want to have In-band Reg support, but   
that's another matter).


It's required for Intermediate IM Server.

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

Re: [Standards] NEW: XEP-0243 (XMPP Server Compliance 2009)

[Peter Saint-Andre]

On 05/29/2008 5:10 PM, Dave Cridland wrote:
> On Wed May 28 23:24:13 2008, XMPP Extensions Editor wrote:
>> Version 0.1 of XEP-0243 (XMPP Server Compliance 2009) has been released.
>>
>> Abstract: This document defines XMPP server compliance levels for 2009.
>>
>> Changelog: Initial published version, incorporating Council feedback.
>> (psa)
>>
>> Diff: N/A
>>
>> URL: http://www.xmpp.org/extensions/xep-0243.html
> 
> A few notes:
> 
> 1) I talked to Isode's marketing department, and the consensus was that
> having "Basic" and "Intermediate" doesn't make much sense. Having
> "Standard" and "Advanced" is likely to get more buy-in - nobody wants to
> call themselves Basic (It sounds like "Rubbish"), and Intermediate
> implies an Advanced somewhere. (The goal here would be that Standard is
> relatively easy for newcomers to get to, Advanced is where we want
> everyone to get to soon - inserting an Intermediate is okay later).

Ah yes it's all about marketing. :)

Does "standard" make it sound like anything else is "non-standard"? How
about "core" and "advanced"?

> 2) Also from our marketing dept: It's only a certification level if
> there's a certificate. Compliance levels are okay, even without formal
> compliance testing.

What exactly is a certificate? A piece of paper or a little icon that
you slap on your website or something else?

We won't have formal compliance testing anytime soon I think, but if we
put some effort into the interop network then we can at least have
something stronger than mere self-reports if you can't be certified
without participating there.

> 3) In other news, I'm still not sure about In-Band Registration being
> required anywhere. It's not because it's hard to do, it's because I
> don't think it's worth having a required feature that won't be needed
> nor used by the vast majority of deployments. I can see it's a good plan
> for public servers, of course.

Is it still in the client suites? I thought I had removed it from the
server suites.

> 4) I think that, realistically, we should promote deployment of PEP -
> therefore, this ought to be there. Changing Intermediate to Advanced
> helps here, since we can push boundaries further.

/me nods

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)

[Peter Saint-Andre]

On 05/30/2008 12:14 PM, Tim Julien wrote:
> One of the first things I'm going to want to do is add ice-udp (we have
> a reliable UDP impl) as a transport 

Isn't reliable UDP different from UDP? Or would you just negotiate
ice-udp and if your UDP stack provides reliable UDP that would just fall
out from the negotiation?

> (and ice-tcp when we get that spec).

Yes, we need to define that one. It should be pretty straightforward.

> Do you envision those negotiations occurring after session-accept, like
> Socks5 and IBB in this spec, or before session-accept like in jingle
> audio / video over RTP?

Probably before, since they would function just like ICE in the voice
and video examples (start sending candidates even before you receive the
session-accept).

/psa



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] 2009 compliance suites?

[Peter Saint-Andre]

On 05/30/2008 12:39 PM, Kevin Smith wrote:
> On Fri, May 30, 2008 at 7:33 PM, JabberForum
> <[EMAIL PROTECTED]> wrote:
>>> I like the thought, but we can't require developers to implement
>>> experimental specs. Maybe for 2010. ;-)
>> ...or Peter can work harder to get this spec out of the experimental
>> state very soon! :D
> 
> Sure, we know Peter's one of the least contributing members of the
> community after all...

Well it had dependencies. We need to finish the core Jingle specs first,
and I'm actively gathering implementation feedback on those...

P

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

[Standards] rfc3920bis: proposed certificate text

[Peter Saint-Andre]

15.2.  Certificates

   Channel encryption of an XML stream using Transport Layer Security as
   described under Section 6, and in some cases also authentication as
   described under Section 7, is commonly based on a digital certificate
   presented by the receiving entity (or, in the case of mutual
   authentication, both the receiving entity and the initiating entity).
   This section describes best practices regarding the generation of
   digital certificates to be presented by XMPP entities and the
   verification of digital certificates presented by XMPP entities.

15.2.1.  Certificate Generation

15.2.1.1.  Server Certificates

   In a digital certificate to be presented by an XMPP server or service
   (i.e., a SERVER CERTIFICATE), it is RECOMMENDED for the certificate
   to include one or more JIDs (i.e., domain identifiers) associated
   with domains serviced at the server.  The representations described
   in the following sections are RECOMMENDED.  These representations are
   described in preference order.

15.2.1.1.1.  Service Name

   A server's domain identifier SHOULD be represented as a service name,
   i.e., as an otherName field of type "id-on-dnsSRV" as specified in
   [X509-SRV].

15.2.1.1.2.  DNS Name

   A server's domain identifier SHOULD be represented as a DNS name,
   i.e., as a subjectAltName extension of type dNSName.

   The DNS name MAY contain the wildcard character '*'.  The wildcard
   character applies only to the left-most domain name component or
   component fragment and match any single component or component
   fragment.  For instance, a DNS name of *.example.com matches
   foo.example.com but not bar.foo.example.com or example.com itself;
   similarly, a DNS name of im*.example.net matches im1.example.net and
   im2.example.net but not chat.example.net or example.net itself.

15.2.1.1.3.  XMPP OID

   A server's domain identifier MAY be represented as an XMPP OID, i.e.,
   as a UTF8String within an otherName entity inside the subjectAltName,
   using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under
   Section 15.2.1.3.  In server certificates, this representation is
   included for the sake of backward-compatibility.

15.2.1.1.4.  Common Name

   A server's domain identifier MUST NOT be represented as a Common
   Name; instead, the Common Name field MUST be reserved for
   representation of a human-friendly name.

15.2.1.1.5.  Examples

   For our first (relatively simple) example, consider a company called
   "Example Products, Inc."  It hosts an XMPP service at
   "im.example.com" (i.e., user addresses at the service are of the form
   "[EMAIL PROTECTED]"), and SRV lookups for the xmpp-client and xmpp-
   server services at "im.example.com" yield one machine, called
   "x.example.com", as follows:

   _xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com
   _xmpp-server._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com

   The certificate presented when connecting to x.example.com contains
   the following representations:

   subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.im.example.com
   subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.im.example.com
   subjectAltName=dNSName:im.example.com
   subjectAltName=otherName:id-on-xmppAddr;UTF8:im.example.com
   CN=Example Products, Inc.

   For our second (more complex) example, consider an ISP called
   "Example Internet Services".  It hosts an XMPP service at
   "example.net" (i.e., user addresses at the service are of the form
   "[EMAIL PROTECTED]"), but SRV lookups for the xmpp-client and xmpp-
   server services at "example.net" yield two machines ("x1.example.net"
   and "x2.example.net") as follows:

   _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
   _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.
   _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
   _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.

   Example Internet Services also hosts chatrooms at chat.example.net,
   and provides SRV records for those services as well.  It also may
   provide other such services in the future, so it wishes to represent
   a wildcard in its certificate to handle future growth.

   The certificate presented when connecting to either x1.example.net or
   x2.example.net contains the following representations:

   subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.example.net
   subjectAltName=otherName:id-on-dnsSRV:_xmpp-client.chat.example.net
   subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.example.net
   subjectAltName=otherName:id-on-dnsSRV:_xmpp-server.chat.example.net
   subjectAltName=dNSName:example.net
   subjectAltName=dNSName:*.example.net
   subjectAltName=otherName:id-on-xmppAddr;UTF8:example.net
   subjectAltName=otherName:id-on-xmppAddr;UTF8:chat.example.net
   CN=Example Internet Services

15.2.1.2.  Client Certificates

   In a digital certificate to be presented by an XMPP 

Re: [Standards] TLS certificate fun

[Peter Saint-Andre]

On 05/13/2008 2:47 PM, Dave Cridland wrote:
> On Tue May 13 20:37:39 2008, Justin Karneges wrote:
>> On Tuesday 13 May 2008 11:40 am, Dave Cridland wrote:
>> > On Tue May 13 19:29:33 2008, Justin Karneges wrote:
>> > > Two sets?
>> >
>> > Yes. One that says "If any xmppAddr is present, use only xmppAddr",
>> > another that says "but fallback to dNSName". This is okay as long as
>> > both ends know which identities are authenticated.
>>
>> 3920, section 14.2, case #1 essentially says that if the xmpp field is
>> present
>> then use it, otherwise fall back to dNSName (and then commonName). 
>> Where is
>> the other set of rules?
>>
>>
> Hmmm... I suppose you could read that as the method for checking
> certificates, and 6.4.2 as the method for generating them. I think both
> could be a lot clearer, though.

Is the new text clearer?

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-05.html#security-certificates

Perhaps I'll post it to the list here as a new thread so that folks can
comment on it

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)

[Dirk Meyer]

XMPP Extensions Editor wrote:
> Version 0.3 of XEP-0234 (Jingle File Transfer) has been released.
>
> URL: http://www.xmpp.org/extensions/xep-0234.html

The caption of example 12 is wrong, the initiator acknowledges
session-accept.


Dirk

-- 
Only Irish coffee provides in a single glass all four essential food groups --
alcohol, caffeine, sugar, and fat.
-- Alex Levine