XEP-xxxx: Pubsub Signing

Abstract
Specifies a mechanism to sign pubsub items
Author
Jérôme Poisson
Copyright
© 2022 – 2022 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

ProtoXEP

WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <https://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
Type
Standards Track
Version
0.0.2 (2022-10-20)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

1. Introduction

There are few ways to authenticate items published via Publish-Subscribe (XEP-0060) [1], and none of them are secure: the publish attribute defined by the pubsub service is not mandatory and can be spoofed by the service itself, and some XEPs such as Microblogging Over XMPP (XEP-0277) [2] have their own mechanism (like <author/> qualified by "http://www.w3.org/2005/Atom" namespace) that is even easier to spoof.

This specification proposes a framework for attaching cryptographic signatures to pubsub items, allowing strong authentication of item authors. This specification only defines the framework, it is designed to be extended by other specifications to use various cryptographic algorithms.

2. Glossary

3. Requirements

The design goals of this XEP are:

4. Overview

To sign a pubsub item, the signature and the signed data are separated. Signed data is a wrapper element comprising essential data such as signers, and the item to be signed. The wrapper element is then normalized, serialized and signed. The signature and additional data of the wrapper element are then publised as Pubsub Attachments (XEP-0470) [3]. In case of multiple signers, each signer publish their own signature as an attachment.

To verify a signature, the process is similiar: the receiving client builds the same wrapper element, normalize and serialize it, and uses it to validate the given signature(s).

5. Signing a Pubsub Item

To sign a pubsub item, a <sign-data/> wrapper element qualified by the 'urn:xmpp:pubsub-signature:0' namespace is created. This element MUST contain at least one 'to' element which MUST have a 'jid' attribute whose value is the intended recipient's XMPP address. The XMPP address found in the 'to' element's 'jid' attribute SHOULD be without Resourcepart (i.e., a bare JID).

The <sign-data/> element MUST contain exactly one <time/> element. The <time/> element MUST have a 'stamp' attribute which contains the timestamp of the moment when the element is being signed in the DateTime format as specified in XMPP Date and Time Profiles (XEP-0082) [4]

The <sign-data/> element MUST contain one or more <signer/> element(s) which MUST possess a 'jid' attribute whose value is the bare JID of the signer.

One or more external elements specified by signing profile MAY be added

The item to sign MUST be added as a child of the <sign-data/> element. If the wrapped <item/> element possesses a 'publisher' attribute, it MUST be removed when added to the wrapper element. As item ID can be added or modified by the Pubsub/PEP service, if the <item/> has an 'id' attribute, it MUST be removed too when added to the wrapper element, thus the item ID is not part of the signed data.

Then the resulting item is put to canonical form by applying C14N v2.0 specification.

The resulting element in canonical form is then serialized and signed.

Below is an example of wrapper element:

Example 1. Wrapper Element (Before Normalization)
    <sign-data>
      <to jid='juliet@capulet.lit' />
      <time stamp='2022-10-16T18:39:03Z' />
      <signer>juliet@capulet.lit</signer>
      <item>
        <entry xmlns='http://www.w3.org/2005/Atom'>
          <author>
            <name>Juliet Capulet</name>
            <uri>xmpp:juliet@capulet.lit</uri>
          </author>
          <title type='text'>She is so pretty! </title>
          <published>2022-10-16T18:39:02Z</published>
        </entry>
      </item>
    </sign-data>

The normalized form is as follow:

Example 2. Wrapper Element (After Normalization)
<sign-data><to jid="juliet@capulet.lit"></to><time stamp="2022-10-16T18:39:03Z"></time><signer>juliet@capulet.lit</signer><item><entry xmlns="http://www.w3.org/2005/Atom"><author><name>Juliet Capulet</name><uri>xmpp:juliet@capulet.lit</uri></author><title type="text">She is so pretty!</title><published>2022-10-16T18:39:02Z</published></entry></item></sign-data>

The signature is then put as an Pubsub Attachments (XEP-0470) [3]. The attachment is a <signature/> element qualified by the 'urn:xmpp:pubsub-signing:0' namespace. The attachment MUST contain the same <time/> and <signer/> elements in the same order as in the <sign-data/> element. If any signing profile extra elements have been used in <sign-data/>, they MUST be added too in the same order as in <sign-data/>. Then the signature is added in an element specified in the signing profile specification.

Each signer entity MUST publish a <signature/> attachment signed with their own encryption keys.

If the pubsub item is encrypted, the signature MUST be done on the plain text version of the item before the encryption of the item. The <signature/> attachment SHOULD be encrypted too.

Example 3. Juliet Publish Her Signature as an Attachment
  <iq from='juliet@capulut.lit/chamber'
    id='signature_1'
    to='juliet@capulet.lit'
    type='set'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:pubsub-attachments:1/xmpp:juliet@capulet.lit?;node=urn%3Axmpp%3Amicroblog%3A0;item=random-thoughts-12bd'>
      <item id='juliet@capulet.lit'>
        <attachments>
          <signature xmlns='urn:xmpp:pubsub-signing:0' timestamp="2022-10-16T18:39:04Z">
            <time stamp='2022-10-16T18:39:03Z' />
            <signer>juliet@capulet.lit</signer>
            <example-signature xmlns='https://example.org/signature'>
              <!-- SOME PAYLOAD -->
            </example-signature>
          </signature>
        </attachments>
      </item>
    </publish>
  </pubsub>
</iq>
  

5.1 rationales

The reason we use Pubsub Attachments (XEP-0470) [3] instead of directly signing the target item is that we need to be backwards compatible, so we cannot replace the target item with another element, nor is it possible to add a sibling element to item's payload (this would not be compliant with Publish-Subscribe (XEP-0060) [1] specification). This requires detaching the signature from the <item/> element itself, and Pubsub Attachments (XEP-0470) [3] are dedicated to attaching data to items, so a viable solution.

5.2 Summarizing

To summarize signatures as explained in Pubsub Attachments (XEP-0470) [3] the <signer/> elements are grouped into a <signature/> element qualified by the 'urn:xmpp:pubsub-signing:0' namespace. This allows a client to easily know that an item is signed, and to obtain the IDs of attachments that need to be retrieved to validate signatures.

Example 4. Juliet Get Summary of Signatures of an Item
  <iq from='juliet@capulet.lit'
    id='summary_123'
    to='juliet@capulet.lit/chamber'
    type='result'>
    <pubsub xmlns='http://jabber.org/protocol/pubsub'>
      <items node='urn:xmpp:pubsub-attachments:summary:1/urn:xmpp:microblog:0'>
        <item id='some-post-with-several-signatures-0adf'>
          <summary xmlns='urn:xmpp:pubsub-attachments:summary:1'>
            <!-- … -->

            <signature xmlns='urn:xmpp:pubsub-signing:0' >
              <signer>juliet@capulet.lit</signer>
              <signer>romemo@montague.lit</signer>
            </signature>

            <!-- … -->
          </summary>
        </item>
      </items>
    </pubsub>
  </iq>
  

5.3 Signature Validation

Once one or more signatures have been found in an item attachment, a client SHOULD validate them. To do this, it builds a wrapper element with the target item as explained in Signing a Pubsub Item, and validate it with each signature. Validation mechanism depends of the signing profile.

6. Business Rules

C14N 2.0 defines parameters for the algorithm. For this specification, default values MUST be used, i.e. IgnoreComments is true, TrimTextNodes is true, PrefixRewrite is none, and QNameAware is the empty set. In other terms: there must be no comments, text nodes must be trimmed, prefixes are left unchanged, and no nodes must be processed as QName-valued.

Once the signature has been validated, it's the original item which MUST be used, as usual, not the normalized form. The original item has attributes missing from the normalized form ('published' and 'id' attribute), and spaces are trimmed, but they may be significant (e.g. in a dataform <value/>).

It is essential to use the same <to/>, <time/>, <signer/> and signing profile extra elements in the <signature/> element put in attachment and in wrapper <sign-data/> element used for signed data, as it is necessary for receiving client to re-build the wrapper element and then validate the signature.

7. Implementation Notes

The client validating signatures should display a message or indicator depending on the validation result:

8. Discovering Support

If a client supports the protocol specified in this XEP, it MUST advertise it by including the "urn:xmpp:pubsub-signing:0" discovery feature in response to a Service Discovery (XEP-0030) [5] information request:

Example 5. Service Discovery information request
<iq type='get'
    from='juliet@example.org/chamber'
    to='romeo@example.org/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
Example 6. Service Discovery information response
<iq type='result'
    from='romeo@example.org/orchard'
    to='juliet@example.org/chamber'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='urn:xmpp:pubsub-signing:0'/>
    ...
  </query>
</iq>

9. Security Considerations

Signature is intimely linked to the trust in the fingerprint of the encryption keys. A warning SHOULD be displayed by a client if a signature is valid but the signing entity's fingerprints are not trusted. Trust should be done through an external channel (outside of XMPP), preferably face-to-face.

Security considerations of the signing profile applies.

10. IANA Considerations

TODO

11. XMPP Registrar Considerations

TODO

12. XML Schema

TODO

13. Acknowledgements

Thanks to NLnet foundation/NGI0 Discovery for funding.


Appendices

Appendix A: Document Information

Series
XEP
Number
xxxx
Publisher
XMPP Standards Foundation
Status
ProtoXEP
Type
Standards Track
Version
0.0.2
Last Updated
2022-10-20
Approving Body
XMPP Council
Dependencies
XMPP Core, XEP-0001, XEP-0004, XEP-0060, XEP-0470
Supersedes
None
Superseded By
None
Short Name
pubsub-signing

This document in other formats: XML  PDF

Appendix B: Author Information

Jérôme Poisson
Email
goffi@goffi.org
JabberID
goffi@jabber.fr

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.

2. XEP-0277: Microblogging over XMPP <https://xmpp.org/extensions/xep-0277.html>.

3. XEP-0470: Pubsub Attachments <https://xmpp.org/extensions/xep-0470.html>.

4. XEP-0082: XMPP Date and Time Profiles <https://xmpp.org/extensions/xep-0082.html>.

5. XEP-0030: Service Discovery <https://xmpp.org/extensions/xep-0030.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

  1. Version 0.0.2 (2022-10-20)
    jp
  2. Version 0.0.1 (2022-10-17)

    First draft.

    jp

Appendix I: Bib(La)TeX Entry

@report{poisson2022pubsub-signing,
  title = {Pubsub Signing},
  author = {Poisson, Jérôme},
  type = {XEP},
  number = {xxxx},
  version = {0.0.2},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-xxxx.html},
  date = {2022-10-17/2022-10-20},
}

END