On 10/07/2011 12:22 PM, "Martin J. Dürst" wrote:
Hello Stephen,
On 2011/10/07 17:54, Stephen Farrell wrote:
Hi Phill,
Oauth [1] uses ""application/x-www-form-urlencoded" format as defined by
[W3C.REC-html401-19991224]" all over the place to solve basically
this problem but in the context of HTTP URLs which has to be worse
than for a new URI scheme.
Why not do the same here?
Are you thinking about this for escaping characters such as slashes?
Right. Sorry I should've been clearer. I meant use base64 like pretty
much all other crypyo->text stuff and then do the
application/x-www-form-urlencoded thing.
As for Phil's original ideas, if there's a security issue with
distinguishing upper- and lowercase filenames on Windows, then
abandoning base64 may be a good idea. I wouldn't know of and couldn't
imagine a structural security issue, but then I'm no security expert,
but there's certainly some erosion, up to one bit per 6 bits if all of
the characters are alphabetic.
I don't know of a real use-case where windows case sensitive file
names are a real issue.
What I still don't understand is where the pressure for having to have
the digest and part of the URI path needing to be the same comes from.
If I want to have a digest protection for a page directly at
http://www.example.org/, shouldn't I be able to do so? I tried to ask
about this previously, but I still didn't get the point, sorry.
I'm not sure what you're asking;-) But, if we use b64+form encoding
then does this question go away?
S.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
