On Aug 19, 2009, at 3:19 AM, Roberto Ostinelli wrote:
hello,
are there any news about this?
I'm working a Proto-XEP which discusses the design of digital
signatures in XMPP, a prelude to providing a specification in this
area. It's a nasty topic. I hope to have this proto-XEP in the inbox
soon.
i'm currently signing portions of stanzas in a way similar to:
<iq>
<my_protocol>
<transport>
[...]
</transport>
<sign>...</sign>
</my_protocol >
</iq>
where <sign/> contains the signature of <transport/>. i'd love to
have a more XMPP native way of doing so.
Given that XMPP's use of XML based, use of something other than XML
DSIG is going to require significant reinvention of technology and
disallow reuse of existing XML DSIG implementations.
wandering if something like:
<iq from='{sender}'
to='{recipient}'
xml:lang='en'
type='set'
id='{iq-id}'
signature='{base64-encoded-signature}'>
[...]
</iq>
where signature could for instance be computed on the string
concatenation of all iq attributes and length of the stanza.
in pseudo-code that would be (\n means the Unicode code point U+000A
commonly called newline):
Signature = Base64(RSA-Private-Key-Encrypt(RequestHash));
StanzaHash = SHA-1(UTF-8-Encoding-Of(StringToSign));
StringToSign = "from" + "=" + Sender +
"to" + "=" + Recipient +
"xml:lang" + "=" + Lang +
"type" + "=" + Type
"id" + "=" + Id
"content-length" + ":" + LengthOfStanzaContent;
does this make sense? i don't see breaking any backwords
compatibility here..
To me, not much. Stanzas can and do change in transit and a signature
which doesn't take this into account has limited applicability
(basically to peer-to-peer communications).
-- Kurt
