BASE64 Change title, and clarify in text, that this is an encapulating digital
signature approach, an alternative to the encapulated digitial signatures proposal. Minor changes (editorial, cleanup, etc.). Initial published version. Proto-XEP draft. 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 Digital Signatures in Extensible
Messaging and Presence Protocol (&xmpp;) based upon End-to-End Object Encryption
(&E2EEncrypt;) "work in progress". The S/MIME approach defined in &rfc3923; has never been implemented in XMPP clients to the
best of our knowledge, but has some attractive features, especially the ability to
store-and-forward a signed message at a user's server if the user is not online when the
message is received (in the XMPP community this is called "offline storage" and the message is
referred to as an "offline message"). The authors surmise that RFC 3923 has not been
implemented mainly because it adds several new dependencies to XMPP clients, especially MIME
(along with the CPIM and MSGFMT media types). This document explores the possibility of an approach that is similar to but simpler than
RFC 3923. Like the approach detailed in RFC 3923, the approach utilizes encapsulating
digital signatures. Like other encapsulating signature approaches (e.g., &xep0027;), this approach does not
support optimistic signing. 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 sender begins with the cleartext version of the <message/> stanza "S": The sender then performs the steps 1 through 4 from above to generate: And then performs steps 5 through 9 steps, causing the following to be sent: To be added.... The following limitations and caveats apply: Several scenarios are possible when an entity receives an encrypted stanza: In Case #1, the receiving application MUST do one and only one of the following: (1) ignore
the <signed/> extension, (2) ignore the entire stanza, or (3), except where precluded by
the protocol (&rfc6120;), return a <service-unavailable/> error to the sender. In Case #2, the receiving application MUST NOT return a stanza error to the sender, since
this is the success case. In Case #3, the receiving application MAY, except where precluded by the protocol, return a
<not-acceptable/> error to the sender, optionally supplemented by an
application-specific error condition element of <bad-timestamp/> as shown below: In Case #4, the receiving application SHOULD, except as precluded by the protocol, return a
<bad-request/> error to the sender, optionally supplemented by an application-specific
error condition element of <bad-signature/> as shown below: Additionally in Case #4, the receiving application SHOULD NOT present the stanza to the
intended recipient (human or application) and SHOULD provide some explicit alternate
processing of the stanza (which may be to display a message informing the recipient that it
has received a stanza that cannot be verified). Timestamps are included to help prevent replay attacks. All timestamps MUST conform to
&DATETIME; 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: 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. 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. This document borrows ideas and text from End-to-End Object Encryption "work in progress" by
Matthew Miller and Peter Saint-Andre.