Update/fix references.
+Update discussions based upon introduction of Encapsulated Digital Signatures in XMPP, - an alternative to XEP-0285.
+Update discussions based upon introduction of Encapsulated Digital Signatures in XMPP, an + alternative to XEP-0285.
The &xep0027; (XMPP PGP), like the XMPP E2E, uses an encapsulating signature to protects - the signed content from alteration as it is exchanged over an XMPP network. Like - XMPP E2E, it is intended to be an end-to-end solution.
+ the signed content from alteration as it is exchanged over an XMPP network. Like XMPP E2E, + it is intended to be an end-to-end solution.At the time of this writing, XMPP PGP has not been widely implemented (though some - implementations do exist). XMPP PGP appears to have limited applicability.
+ implementations do exist). XMPP PGP appears to have limited applicability. +The &xep0285; (XMPP EgDSIG), like the XMPP E2E and XMPP PGP, uses an encapsulating + signature to protects the signed content from alteration as it is exchanged over an XMPP + network.
+Unlike XMPP E2E and XMPP PGP, the solution is not intended to be strictly end-to-end in + that multiple signers and verifiers where contemplated, now of which is necessarily an end + entity. However, like XMPP E2E, it does not supported optimistic signing.
Alternative approaches have been developed. For instance, the Cross Domain Collaborative @@ -273,11 +289,11 @@ to have applicability limited to the CDCIE.
The &xmpp-dsig-new; (XMPP DSIG) is an encapsulated signature proposal similar to - that encapsulated approach suggested below.
-Unlike CDCIE-CCP approach, XMPP DSIG signatures are not "enveloped" signatures over the - whole stanza but signatures over a manifest and descriptive objects detailing the stanza - contents.
+The &xep0290; (XMPP DSIG) is an encapsulated signature proposal similar to that + signed manifest approach suggested below. This approach is intended to support a wide range of + uses and applications including optimistic signing in general communciations.
+Unlike CDCIE-CCP approach, XMPP DSIG signatures are not "enveloped" signatures over the + whole stanza but signatures over an object which details the stanza contents.
An encapsulating signature is a signature approach that encapsulates the signed content within the signature syntax. An encapsulated signature is a signature approach where the - signature syntax in encapsulated within the structure of the signed content. XMPP E2E - and XMPP PGP are examples of the former. CDCIE-CCP and XMPP DSIG are examples - of the latter.
+ signature syntax in encapsulated within the structure of the signed content. XMPP E2E and + XMPP PGP are examples of the former. CDCIE-CCP and XMPP DSIG are examples of the latter.The following example illustrates, using pseudo language, an encapsulating signature over a &MESSAGE; stanza.
@@ -326,13 +341,13 @@ ]]> -Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E - and XMPP PGP, are generally limited to end-to-end use cases. That is, cases where the - originator of a stanza signs the stanza and send it through the XMPP network to its intended - recipient, and only the intended recipient is expected to make use of the signed content. - Entities between the signer and the intended recipient are expected to forward of the stanza - without regard to the encapsulating signature, and without themselves signing the stanza. - The approach does not require forwarding entities to support the signing extension.
+Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E and + XMPP PGP, are generally limited to end-to-end use cases. That is, cases where the originator + of a stanza signs the stanza and send it through the XMPP network to its intended recipient, + and only the intended recipient is expected to make use of the signed content. Entities + between the signer and the intended recipient are expected to forward of the stanza without + regard to the encapsulating signature, and without themselves signing the stanza. The + approach does not require forwarding entities to support the signing extension.
Simple encapsulating signatures have limited applicability in MUC and PubSub use cases. For
instance, an occupant can sign its submissions to the service for the benefit of the service
and the service can sign reflected stanzas to occupants. In providing non-anonymous chat
@@ -523,26 +538,26 @@
Some users design the ability to optimistic signing of stanzas. That is, to sign
all stanzas adhere to a configured criteria, such as all &MESSAGE; stanzas, they send. A key
- aspect of optimistic signing is that receiving entities not supporting the signing
- extension should be able to make use the message content (excluding the signature
- information) while those receiving entities supporting the extension can make use of the
- message content and the signature information.
Optimistic signing is available in E-mail through the use of S/MIME detached signatures. Use of S/MIME detached signatures can be problematic. Mail systems, especially restribution services such as mailing lists, are notorious for changing the signed content and hence breaking the signature.
In XMPP, as stanzas are generally altered in transit and hence optimistic signing will be fragile at best. Through use of selective signing and manifesting, issues may be mitigated - to some degree. It is doubtful that a solution exists that provides optimistic signing and + to some degree. It is doubtful that a solution exists that provides optimistic signing and reliability verification.
One possible optimistic signing solution is for stanzas to carry alternative sets of - content, an unsigned content alternative and a signed content alternative. The premise of - this approach is that an entity supporting the signing extension could make use of the - signed content alternative while an entity not supporting the signing extension could make - use of the unsigned content alternative. The approach has been suggested to as a mechanism - for support extension-unaware entities downstream of extension-unware groupchat (or like) - services use of the stanza content.
+One possible optimistic signing solution is for stanzas to carry alternative + sets of content, an unsigned content alternative and a signed content alternative. The + premise of this approach is that an entity supporting the signing extension could make use + of the signed content alternative while an entity not supporting the signing extension + could make use of the unsigned content alternative. The approach has been suggested to as + a mechanism for support extension-unaware entities downstream of extension-unware + groupchat (or like) services use of the stanza content.
The following example not only illustrate this approach, but highlights some of the issues with this approach:
Initial published version.
Merge manifest and schema-desc objects.
+Initial published version.
+This document is one of two proposals for digital signatures in XMPP. It + is expected that only one of these proposals be progressed beyond Experimental on + the Standards Track.
+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.
+ 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;.
+ 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 @@ -76,10 +91,10 @@
This is modified prior to signing as follows:
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.
@@ -145,13 +142,6 @@The signer than computes the SignatureValue element, processing the Signature element as +
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.
@@ -233,45 +200,22 @@