From 35029d1c7ed3c98b162ba9da76804440bd471828 Mon Sep 17 00:00:00 2001 From: stpeter Date: Wed, 26 Jan 2011 18:52:00 -0700 Subject: [PATCH] initial published version --- xep-0290.xml | 388 +++++++++++++++++++++++++++++++++++++++++++++++++++ xep-0291.xml | 147 +++++++++++++++++++ 2 files changed, 535 insertions(+) create mode 100644 xep-0290.xml create mode 100644 xep-0291.xml diff --git a/xep-0290.xml b/xep-0290.xml new file mode 100644 index 00000000..e0233a41 --- /dev/null +++ b/xep-0290.xml @@ -0,0 +1,388 @@ + + +%ents; +]> + + +
+ Encapsulated Digital Signatures in XMPP + This document provides a technical specification for Encapsulated Digital + Signatures in the Extensible Messaging and Presence Protocol (XMPP). + &LEGALNOTICE; + 0290 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + + + + N/A + &kdz; + + 0.1 + 2011-01-26 + psa +

Initial published version.

 + + + 0.0.1 + 2010-11-29 + kdz + +

Proto-XEP draft.

+ + +
+ + +

This document provides a technical specification for Encapsulated Digital Signatures in + Extensible Messaging and Presence Protocol (&xmpp;).

+

XMPP Digital Signatures may be used to provide signer authentication, data integrity, + non-repudiation, and other security services.

+

This extension is intended to be highly flexible, supporting a wide range of applications. + The extension not only supports signing by the originator, but by other entities which + handle XMPP stanzas. Multiple entities may independently sign a stanza.

+

A signed manifest approach is used to allow selective signing (only select elements + may be included in the manifest) and to allow flexibility in handling verification + errors.

+

This extension is intended to support optimistic signing.

+

This document offers an encapsulated signature approach based upon &w3xmlsig; (XMLDSIG). + Implementations of this extension not required to fully implement the XML DSIG + specification, they may implement only the minimal subset necessary to support this + extension.

+

It is noted that a number of object-level XMPP digital signature extensions have been + specified over the years. These include &rfc3923; (XMPP E2E), &xep0116; (XMPP PGP), + and &xep0285;. The limited applicability of encapsulating signature approaches in XMPP + is discussed in &xep0274;.

+ + +

The process that a sending agent follows for securing stanzas is very similar regardless + of the form of stanza (i.e., <iq/>, <message/>, or <presence/>).

+ +

The signer begins with the cleartext version of the <message/> stanza "S":

+ + 8996aef0-061d-012d-347a-549a200771aa + Wherefore art thou, Romeo? + + ]]> + +

This is modified prior to signing as follows:

+
    +
  • Default attribute values are added. (Namespace declarations are not modified.)
    • +
  • Each child element of the stanza is augmented by a id attribute + qualified in the urn:xmpp:dsig:0 namespace. As these attributes are used to + identify the element within a manifest, they must be sufficient unique.
    • +
+ + 8996aef0-061d-012d-347a-549a200771aa + Wherefore art thou, Romeo? + + ]]> + +

The signer builds a stanza description object containing a signer element, the stanza + element, and a timestamp element. The signer element value is the bare JID of the + signing entity. When the signing entity is a service entity, the JID may only contain + service domain. The stanza element is the stanza prepared above with each of its element + replaced by an reference element.

+ + juliet@capulet.net + + xxxx-1 + xxxx-2 + + 2010-11-11T13:33:00.123Z + +]]> + +

The signer then builds an XMLDSIG Manifest object which references each element via the + xmpp:dsig:ref:0 URN and provides a digest over the element (after it has + been modified to include a d:id attribute) as transformed by the transformation + algorithm.

+ + + + + + + ... + + + + + + + ... + + +]]> + +

The signer then builds a SignedInfo element.

+ + + + + + + + ... + + + + + + + ... + + +]]> + +

And then produces a Signature element:

+ + + + + + + + + ... + + + + + + + ... + + + + + + juliet@capulet.net + + xxxx-1 + xxxx-2 + + 2010-11-11T13:33:00.123Z + + + + + + + + + + ... + + + + + + + ... + + + + + ]]> + +

The signer than computes the SignatureValue element, processing the Signature element as + a detached signature, and replaces the empty Signature element with it. Finally, the + signer inserts the Signature element into stanza and forwards the stanza as it normally + would.

+ + 8996aef0-061d-012d-347a-549a200771aa + Wherefore art thou, Romeo? + + + + + + + + + ... + + + + + + + ... + + + ... + + + juliet@capulet.net + + xxxx-1 + xxxx-2 + + 2010-11-11T13:33:00.123Z + + + + + + + + + + ... + + + + + + + ... + + + + + + ]]> + + + +

For referenced elements of a stanza, the referenced element is normalized (omitting + comments), as detailed in &w3canon;, as a document subset of a document containing a + stream element containing the appropriate jabber:client stanza element containing the + stanza with the referenced elements. Note that jabber:client stanzas are used when + constructing this document even when a server is signing a stanza to be sent to another + server.

+

For the stanza in Example 2, the input document would be:

+ + + 8996aef0-061d-012d-347a-549a200771aa + Wherefore art thou, Romeo? + + + ]]> + +

The canonical form of element referenced by urn:xmpp:dsig:ref:0#xxx-1 would + be:

+ 8996aef0-061d-012d-347a-549a200771aa]]> + + + +

The URI 'uri:xmpp:dsig:ref:0#xxxx" refers to the child element of the stanza which + contains the 'uri:xmpp:dsig:0' 'id' attribute with the value "xxxx".

+ + + +

Timestamps are included to help prevent replay attacks. All timestamps MUST conform to + &rfc3339; and be presented as UTC with no offset, always including the seconds and + fractions of a second to three digits (resulting in a datetime 24 characters in length). + Absent a local adjustment to the sending agent's perceived time or the underlying clock + time, the sending agent MUST ensure that the timestamps it sends to the receiver + increase monotonically (if necessary by incrementing the seconds fraction in the + timestamp if the clock returns the same time for multiple requests). The following rules + apply to the receiving application:

+ +
    +
  • It MUST verify that the timestamp received is within five minutes of the current + time, except as described below for offline messages.
    • +
  • If the foregoing check fails, the timestamp SHOULD be presented to the receiving + entity (human or application) marked with descriptive text indicating "old + timestamp" or "future timestamp" and the receiving entity MAY return a stanza error + to the sender (except as precluded in the protocol).
    • +
+ +

The foregoing timestamp checks assume that the recipient is online when the message is + received. However, if the recipient is offline then the server will probably store the + message for delivery when the recipient is next online (offline storage does not apply + to <iq/> or <presence/> stanzas, only <message/> stanzas). As + described in &xep0160;, when sending an offline message to the recipient, the server + SHOULD include delayed delivery data as specified in &xep0203; so that the recipient + knows that this is an offline message and also knows the original time of receipt at the + server. In this case, the recipient SHOULD verify that the timestamp received in the + encrypted message is within five minutes of the time stamped by the recipient's server + in the <delay/> element.

+ + + +

All implementations MUST support the following algorithms. Implementations MAY support + other algorithms as well.

+
    +
  • TBD
    • +
+ + + +

To participate in end-to-end signing using the methods defined in this document, a client + needs to possess an X.509 certificate. It is expected that many clients will generate + their own (self-signed) certificates rather than obtain a certificate issued by a + certification authority (CA). In any case the certificate MUST include an XMPP address + that is represented using the ASN.1 Object Identifier "id-on-xmppAddr" as specified in + Section 5.1.1 of RFC 3920bis.

+ + + +

TBD.

+ + + + +

A URN sub-namespace of signed content for the Extensible Messaging and Presence + Protocol (XMPP) is defined as follows.

+
+ +
URI:
+
urn:xmpp:dsig
+ + +
Specification:
+
ProtoXEP
+ + +
Description:
+
This is an XML namespace name of signed content for the Extensible Messaging + and Presence Protocol as defined by ProtoXEP.
+ + +
Registrant Contact:
+
XSF
+ +
+ + + diff --git a/xep-0291.xml b/xep-0291.xml new file mode 100644 index 00000000..b335a402 --- /dev/null +++ b/xep-0291.xml @@ -0,0 +1,147 @@ + + +%ents; +]> + + +
+ Service Delegation + This specification defines an approach for users to delegate certain services (e.g. pubsub) to alternative JIDs. + &LEGALNOTICE; + 0291 + Experimental + Standards Track + Standards + + XMPP Core + + + + NOT_YET_ASSIGNED + &infiniti; + + 0.1 + 2011-01-26 + psa +

Initial published version.

 + + + 0.0.1 + 2010-01-05 + jk +

First draft.

 + +
+ + +

It is common to use XMPP user accounts for identity. Many features for user accounts have been proposed (for example, &xep0084;, &xep0277;, etc), and this list only grows as XMPP heads into social networking territory. However, not every XMPP server in the world supports every feature, nor can this ever be expected, and this limits the usefulness of the XMPP user account identity. Also, even when servers do support a feature it may not be clear how to bind an identity to it (see the never-solved problem of learning where a user's generic &xep0060; service is, in the absence of &xep0163;). Organizations such as Buddycloud and Livefyre have recognized the need to be able to offer features to existing standard XMPP accounts by offering proprietary service delegation mechanisms. This specification proposes a Standards Track solution for discovering external services associated with XMPP user identities.

+ + + + +

To learn of delegate services for a user, query the bare JID of the user:

+ + + + ]]> + + + + + + + ]]> +

In the above example, we learn that "chess" related communication should go through the "bob@chess.example.net" JID rather than the user's own JID ("bob@example.com").

+ + +

As it is expected that most servers will not even support the ability to query user accounts for delegate services, it should be possible to contact a third-party or global registry holding the same information, to be queried in much the same way:

+ + + + ]]> + + + + + + + ]]> + + +

Here's how a user adds a mapping to the registry:

+ + + + + + ]]> + + ]]> +

The registry will add the new service to the list of mapped services for the sender JID.

+

To remove a service from the list, submit without a jid attribute:

+ + + + + + ]]> + + ]]> + + +

Whether a delegate JID is discovered directly or via registry, the mapping is an assertion made by the user only and not by the delegate. This may have security implications. For example, a third party should not allow the user to pose as the delegate, nor should the mapping be considered an endorsement by the delegate, since anyone can assert any delegate. However, these types of things could be allowed if third parties confirm with the delegate that the association exists.

+

Here's how to query a delegate JID to confirm if it is indeed associated with a specific user for a specific service type:

+ + + + ]]> +

Note that the user JID expected to be associated with the delegate must be provided in the request. It is not possible to query a delegate to determine the user JID, since a single delegate may act for many users.

+

Success response means the association exists:

+ + ]]> + + + + + +

Applications that are configured to use a third-party registry SHOULD still be able to query user accounts directly. For performance reasons, it is recommended to query both the user account and the registry simultaneously, and take whichever answer arrives first. If one of the queries results in an error, then the application should wait for the other query to complete before assuming no such delegate records exists.

+

If both queries return errors, or a success result does not contain an entry for some desired delegate service, it can be assumed that the desired service is provided by the user account itself (not delegated).

+ + +

It is RECOMMENDED that discovery or confirmation of delegate information be cached indefinitely and refreshed no more frequently than every 24 hours. Data refreshing should not block access to existing information. If over 24 hours pass since the last time delegate information was needed, the application should continue to use the old data while independently firing off a task to refresh the data. This way, latency associated with a particular user delegation only occurs the first time a user is ever seen.

+ + + + +

As discussed above, a delegate mapping is an assertion by the user only. If the user should be allowed to act for the delegate, or if the user should be considered endorsed by the delegate, then the delegation needs to be confirmed first.

+ + + +

No interaction with &IANA; is required as a result of this document.

+ + + + +

This specification defines the following XML namespace:

+
    +
  • urn:xmpp:tmp:delegate
    • +
+

Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.

+ + + &NSVER; + + + +