To sign a pubsub item, the signature and the signed data are separated. Signed data is a wrapper element comprising essential data such as signatories, 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 &xep0470;. In case of multiple signatories, each signatory publish their own signature as an attachment.
+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 &xep0470;. 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).
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 one or more <signatory/> element(s) which MUST possess a 'jid' attribute whose value is the bare JID of the signatory.
+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 &xep0082;
+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.
@@ -72,7 +86,9 @@Below is an example of wrapper element:
The normalized form is as follow:
-The signature is then put as an &xep0470;. The attachment is a <signature/> element qualified by the 'urn:xmpp:pubsub-signing:0' namespace. The attachment MUST contain the same <signatory/> element 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 signatory entity MUST publish a <signature/> attachment signed with their own encryption keys.
+The signature is then put as an &xep0470;. 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.
To summarize signatures as explained in &xep0470; the <signatory/> 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.
+To summarize signatures as explained in &xep0470; 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.
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.
-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 <signatory/> 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.
+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.
The client validating signatures should display a message or indicator depending on the validation result: