Re: [Standards] New revised version of proposal: Signing Forms
Hello Lance Thanks for your input. Regarding your concerns: >Since signing forms uses OAuth 1, how much from XEP-0235 (OAuth over XMPP) can >be reused here? XEP-0235 already specifies some of these parameters for >generating signatures, which differ from ones in this proposal. I first made an attempt to reuse 0235, but since it was deferred, and I did not get any response from Peter Saint-André (author) regarding the subject (see attached), I left that track. Furthermore, I wanted a solution that did not interfere with underlying architecture or communication principles, for instance like requiring to request tokens separately (like in §2 in XEP-0235), especially avoiding the use of other protocols, like HTTP (items 4 & 9 in §2). > Having spent some time reviewing signing forms against some use cases I might > have for it, I'm really left wondering why not just use XEP-0235 directly? It seemed to be far too different from what I wanted to do. For instance: * It seems to require you're already authenticated. * Requires tokens to be separately fetched using another protocol. * Only signs the stanza attributes, not the content. * Was designed for interaction with pubsub, even though this can obviously be extended. The main obstacle here are the first three points. Signing forms does not require any other interaction that what would normally have been done, and allows a solution to adapt itself easily. If the form requires signing, the client can sign the form, if not, signing is not required. The server (i.e. the one sending the form) determines if signature is necessary. The client needs no pre-knowledge if signing is required or not. >It clearly separates the OAuth data from the user's form data, and provides >error elements for explicit feedback on incorrect or missing parameters which >signing forms currently lacks. Well, such error information could be added easily in error responses to form submissions, if desired. >I understand that embedding OAuth information inside a form is quick & easy, >but 235 is very simple too and can be used in places where forms aren't used. >I'd rather we have a single established way to do OAuth generally rather than >two almost-the-same-but-not-quite methods. But 0235 is not an established way, since it is deferred. The problem I want to avoid is anything that might interfere with how underlying implementation is done, both on clients and servers. Say you have a library that supports IBR. It raises an even when a IBR form is returned, or returns an IBR form as a response to a request. Without any changes to the library itself, you can implement the signature, since it's part of the form. If you place the OAUTH authentication outside, you might need to update the library, something you might not be able to. >I will admit that right now XEP-0235 does need some editing & review, and that >it lacks two key features: indication that OAuth is required, and the optional >inclusion of form fields in the signature. As for requirement indication, I >think we can do that rather easily: > > > > 1.0 > HMAC-SHA1 > > >And for form values in the signature, we can state that if the OAuth request >is used in conjunction with a data form, then the signature process may >include those form values, in the manner described here. I personally believe this is not the best solution, for the reasons described above: * The solution might require changes made to libraries you use. The proposed solution does not. * The changes made to 0235 would be very large, the main two problems being the token requests and use of other protocols. In essence the result would be something completely new anyway. >-- with council hat -- > >XEP-0235 & Signing Forms have overlapping use cases, and while similar have at >least one subtle difference & gotcha (notably the method values are currently >inconsistent). Editing and updating of XEP-0235 could be done to cover the >cases addressed by Signing Forms. However, Signing Forms can *not* be updated >to cover all of the cases addressed by XEP-0235, namely cases which don't >involve data forms (e.g., PubSub subscription requests). This is not a correct assessment. XEP-0235 does not sign the form, only the carrying stanza. This means you can inject anything into the stanza, and it will be assumed to be signed. The signing form proposal signs the actual form parameters, not the stanza carrying the form. This is a difference. So, the deferred 0235 can be used to sign the stanza element, but not the form, while the signing forms proposal signs the contents of a form, but not the stanza carrying the form, even though the form type and to address are included in the signature. So part of the stanza carrying the form is also signed. >As such, I'm inclined to vote -1 for Signing Forms as-is in preference that we >expand and fix XEP-0235 so that it addresses the use cases for Signing Forms. I hope you reconsi
Re: [Standards] New revised version of proposal: Signing Forms
On May 16, 2014, at 10:01 AM, Peter Waher wrote:
> The reason was to stick to the OAUTH algorithm as defiend for the web, where
> BStr is defined as:
>
> BStr:=Escape(method)+'&'+Escape(url)+'&'+Escape(PStr)
>
> (method=GET/POST; etc..)
>
> The closest match in XMPP the method parameter has is the type attribute used
> when submitting the form, and the closest match to the url parameter is the
> to-attribute. It is the actual ‘type’ attribute that is referred to. (I’ve
> made a small change to highlight this.) The form_type parameter is already
> included in PStr:
>
> BStr:=Escape(type)+'&'+Escape(to)+'&'+Escape(PStr)
>
> Clarification now reads:
>
> “The Signature Base String (BStr) is then formed concatenating Escape(type)
> (the 'type' attribute of the form used when submitting the form), Escape(to)
> (the full destination address, including resource, if any) and Escape(PStr),
> using ampersands ('&') as delimiter.“
>
> OK?
>
> Note however, that you can include any parameter in the signature, by posting
> hidden parameters on the form.
-- without council hat --
Since signing forms uses OAuth 1, how much from XEP-0235 (OAuth over XMPP) can
be reused here? XEP-0235 already specifies some of these parameters for
generating signatures, which differ from ones in this proposal.
Having spent some time reviewing signing forms against some use cases I might
have for it, I'm really left wondering why not just use XEP-0235 directly? It
clearly separates the OAuth data from the user's form data, and provides error
elements for explicit feedback on incorrect or missing parameters which signing
forms currently lacks. I understand that embedding OAuth information inside a
form is quick & easy, but 235 is very simple too and can be used in places
where forms aren't used. I'd rather we have a single established way to do
OAuth generally rather than two almost-the-same-but-not-quite methods.
jabber:iq:register
Juliet
Capulet
jul...@capulet.com
F
1.0
HMAC-SHA1
...
...
.. .
.. .
.. .
.. .
I will admit that right now XEP-0235 does need some editing & review, and that
it lacks two key features: indication that OAuth is required, and the optional
inclusion of form fields in the signature. As for requirement indication, I
think we can do that rather easily:
1.0
HMAC-SHA1
And for form values in the signature, we can state that if the OAuth request is
used in conjunction with a data form, then the signature process may include
those form values, in the manner described here.
-- with council hat --
XEP-0235 & Signing Forms have overlapping use cases, and while similar have at
least one subtle difference & gotcha (notably the method values are currently
inconsistent). Editing and updating of XEP-0235 could be done to cover the
cases addressed by Signing Forms. However, Signing Forms can *not* be updated
to cover all of the cases addressed by XEP-0235, namely cases which don't
involve data forms (e.g., PubSub subscription requests).
As such, I'm inclined to vote -1 for Signing Forms as-is in preference that we
expand and fix XEP-0235 so that it addresses the use cases for Signing Forms.
-- Lance
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [Standards] New revised version of proposal: Signing Forms
Hello Dave,
Thanks for the valuable input. Sorry for the delay in responding. I’ll address
your comments and suggestions one at a time:
>Last one on my list. :-)
>
>First off, it's unclear why, in §2.4, PStr does not include the 'from'
>attribute if available? I also suspect it should include the 'to' only if
>given in the stanza, and finally I think your use of "type" should be replaced
>with "form_type" to avoid confusion with the stanza's type attribute.
The reason was to stick to the OAUTH algorithm as defiend for the web, where
BStr is defined as:
BStr:=Escape(method)+'&'+Escape(url)+'&'+Escape(PStr)
(method=GET/POST; etc..)
The closest match in XMPP the method parameter has is the type attribute used
when submitting the form, and the closest match to the url parameter is the
to-attribute. It is the actual ‘type’ attribute that is referred to. (I’ve made
a small change to highlight this.) The form_type parameter is already included
in PStr:
BStr:=Escape(type)+'&'+Escape(to)+'&'+Escape(PStr)
Clarification now reads:
“The Signature Base String (BStr) is then formed concatenating Escape(type)
(the 'type' attribute of the form used when submitting the form), Escape(to)
(the full destination address, including resource, if any) and Escape(PStr),
using ampersands ('&') as delimiter.“
OK?
Note however, that you can include any parameter in the signature, by posting
hidden parameters on the form.
Next, typo - Example 6 should presumably have a title of "PLAINTEXT".
Thanks. Corrected.
Overall, I really think that using the FORM_TYPE here is wrong - it means the
only forms that can be signed are form signing forms, which seems somewhat
introspective. Instead I recommend defining a new signing indicator, perhaps a
field SIGNED. It's not *wonderfully* clear in XEP-0068 whether additional
generic field names such as this, or the oauth ones, can be registered in such
a way, but we can change that to accommodate this.
The reason I feel strongly here is because I'd like to be able to potentially
sign forms such as MUC configurations, and the current proposal essentially
prevents this.
Yes, I was thinking about this also. I was thinking, that instead of defining a
completely new FORM_TYPE, just to define a suffix, for instance
“:signature:oauth1”. This would make it easier for clients to understand.
Examples:
For signed in-band registration with form signature:
jabber:iq:register:signature:oauth1
For in-band registration with CAPTCHA:
urn:xmpp:captcha:signature:oauth1
Generic form signature:
urn:xmpp:xdata:signature:oauth1
Similarly, form types for MUC configuration, etc. could have their FORM_TYPE
suffixed by “:signature:oauth1”.
Would that work?
I have not reviewed this document in terms of security.
On 13 May 2014 13:58, Peter Waher
mailto:peter.wa...@clayster.com>> wrote:
Hello
I had forgotten to add an Acknowledgements section to the previous version.
Here, an updated version with acknowledgements. If I’ve forgotten anybody,
please let me know.
Best regards,
Peter Waher
From: Peter Waher
Sent: den 9 maj 2014 18:12
To: standards@xmpp.org
Cc: XEP Editor (edi...@xmpp.org)
Subject: New revised version of proposal: Signing Forms
Hello
Attached is a revised version of the proposed XEP: Signing Forms.
All input from the community and the council has been addressed, mostly minor:
• Removed links to articles expression opinions.
• Reformulated the reference to SASL in the introduction.
• A reference to Unicode Standard Annex #15, Unicode Normalization
Forms, and NFC normalization has been added.
Please add this to the inbox.
Best regards,
Peter Waher
Re: [Standards] New revised version of proposal: Signing Forms
Last one on my list. :-) First off, it's unclear why, in §2.4, PStr does not include the 'from' attribute if available? I also suspect it should include the 'to' only if given in the stanza, and finally I think your use of "type" should be replaced with "form_type" to avoid confusion with the stanza's type attribute. Next, typo - Example 6 should presumably have a title of "PLAINTEXT". Overall, I really think that using the FORM_TYPE here is wrong - it means the only forms that can be signed are form signing forms, which seems somewhat introspective. Instead I recommend defining a new signing indicator, perhaps a field SIGNED. It's not *wonderfully* clear in XEP-0068 whether additional generic field names such as this, or the oauth ones, can be registered in such a way, but we can change that to accommodate this. The reason I feel strongly here is because I'd like to be able to potentially sign forms such as MUC configurations, and the current proposal essentially prevents this. I have not reviewed this document in terms of security. On 13 May 2014 13:58, Peter Waher wrote: > Hello > > > > I had forgotten to add an Acknowledgements section to the previous > version. Here, an updated version with acknowledgements. If I’ve forgotten > anybody, please let me know. > > > > Best regards, > > Peter Waher > > > > *From:* Peter Waher > *Sent:* den 9 maj 2014 18:12 > *To:* standards@xmpp.org > *Cc:* XEP Editor (edi...@xmpp.org) > *Subject:* New revised version of proposal: Signing Forms > > > > Hello > > > > Attached is a revised version of the proposed XEP: Signing Forms. > > > > All input from the community and the council has been addressed, mostly > minor: > > > > · Removed links to articles expression opinions. > > · Reformulated the reference to SASL in the introduction. > > · A reference to Unicode Standard Annex #15, Unicode > Normalization Forms, and NFC normalization has been added. > > > > Please add this to the inbox. > > > > Best regards, > > Peter Waher > > > > >
