Re: any discussion thread for page encodings?

Hi.

I agree there are no perfect protection for compromised user environment.
but I think if we can do, we have to do to the level we know at least.

I think.
Signed JS has same purpose for keeping JS integrity.

service provider want to make sure the JS codes in user agent are same to
original server sent.
if server sent

crypto.sign("I agree to pay 100");

and user switched the string

crypto.sign("I agree to pay 10");

this can be problem in real field.


var integrity = crypto.getIntegrityValue();

can be one of example for my integrity checking mechanism.

also Signed JS can be (maybe) one of alternatives.

this is very basic concern.

best regards


On Mon, Jul 30, 2012 at 2:01 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Sun, Jul 29, 2012 at 9:46 PM, Mountie Lee <mountie.lee@gmail.com>
> wrote:
> > Hi.
> > thanks for your mail.
> >
> > for "prevent and control"
> > the "same origin" policy is not enough I think.
> >
> > some attackers are focusing to compromise PC environment.
> > many attempts are made on PC level.
> >
> > with "same origin" policy, well designed web application can protect XSS
> or
> > Cross Site Scripting attack.
> >
> > I think we need one of followings.
> > Integrity checking mechanism
> > or
> > protecting DOM object
> >
> > the description "webcrypto based methods should not permit DOM changes"
> > in Transaction Security use cases
> > in http://www.w3.org/wiki/KoreaWebCryptoUseCase
> > is described based on same idea of me.
> >
> > regards
> > mountie.
>
> Thank you for the continued feedback.
>
> Unfortunately, if I'm understanding correctly, such controls as you
> propose have been agreed as out of scope according to our charter, and
> would require rechartering this working group to consider them in
> scope. This is listed under "Out of scope" is the statement
> "access-control mechanisms beyond the enforcement of the same-origin
> policy" at http://www.w3.org/2011/11/webcryptography-charter.html
>
> However, I'm not sure I understand your comments regarding threats to
> the PC level. A user agent cannot protect against a compromised
> operating environment - whether malware, rootkit, or bootkit, these
> attacks can all circumvent the browser security model (as well as the
> OS and smart card security models, so these are not new problems).
> Thus such attacks are out of scope for this WG, beyond possibly noting
> this under security considerations.
>

It's not clear to me what exactly are you envisioning as suitable
> controls. "Protecting DOM object" and "Integrity Checking mechanism"
> are not clear, either in attacks or mitigation. Perhaps you can
> provide an example of an "Attack", an example of a control, and a
> description of how it would mitigate that attack. I just want to make
> sure I've properly understood your question and it's out-of-scope
> ness.
>
> Note that, as I mentioned, the low-level API provides a way for
> applications to provide custom integrity protection (eg: on top of
> that afforded by SSL/TLS, which is the recommended means), by
> protecting any sort of responses that will lead to DOM manipulation.
> Also, please note that both the current low-level API and the previous
> high-level API never directly interacted with the DOM, beyond the
> incorporation of the DOM language for describing asynchronous event
> handling.
>
> If you're trying to prevent 'hostile' JS, then that is not a problem /
> use case for this WG, and is indeed something better addressed at an
> application layer (eg: via CSP).
>
> Regards,
> Ryan
>
> >
> > On Sun, Jul 29, 2012 at 6:07 PM, Ryan Sleevi <sleevi@google.com> wrote:
> >>
> >> On Sun, Jul 29, 2012 at 1:29 AM, Mountie Lee <mountie.lee@gmail.com>
> >> wrote:
> >> > Hi. Ryan.
> >> > yes. I read in charter and use cases for "prevent and control"
> >> > but no details.
> >> >
> >> > I remember someone mentioned "signed JS". but that is not acceptable
> for
> >> > wider use.
> >> >
> >> > can we consider "arguments.callee" (but this is depreciated in
> ECMA-262)
> >> > plus hash?
> >> >
> >> > If webcrypto api provide JS/DOM integrity checking feature in low
> level,
> >> > web developers can use it for many purpose including "prevent and
> >> > control"
> >> >
> >> > regards
> >> > mountie.
> >>
> >> Hi Mountie,
> >>
> >> The intent of "prevent and control" is limited in the scope of same
> >> origin. There are no attempts being made, and it's largely out of
> >> scope for this WG, to try to change or redefine the web security
> >> model. This includes the use of arguments.callee.
> >>
> >> All script executing in the context of the same origin is therefore
> >> able to interact with this API. This is also highlighted in the
> >> editor's draft under Security Concerns. Applications should thus make
> >> use of available functionality, such as CSP, to reduce the risk of
> >> cross-site-scripting and other script related attacks. Any further
> >> refinements are better suited for the charter of the W3C's Web
> >> Application Security Working Group.
> >>
> >> After our recent face-to-face, the question of signed JS, which is a
> >> proposal that had limited qualification and was relayed second-hand,
> >> was raised as a point of concern. Those who originally proposed it are
> >> being asked to further clarify and refine what their use case was, to
> >> better understand where it fits within the scope of this groups
> >> charter.
> >>
> >> Note that with a low-level API, an application could certainly
> >> introduce it's own signature verification methods around script
> >> content that is passed to either JSON.parse or to eval, which afford
> >> application-defined security without requiring this WG to define any
> >> additional special APIs.
> >>
> >> Does that answer your question?
> >>
> >>
> >> >
> >> >
> >> > On Sun, Jul 29, 2012 at 4:39 PM, Ryan Sleevi <sleevi@google.com>
> wrote:
> >> >>
> >> >> On Sat, Jul 28, 2012 at 8:55 PM, Mountie Lee <mountie.lee@gmail.com>
> >> >> wrote:
> >> >> > Hi. Ryan.
> >> >> >
> >> >> > thanks for your answer.
> >> >> >
> >> >> > as my understanding, the initial requirement has include "sign with
> >> >> > user
> >> >> > confirmation".
> >> >> > that means the sign data must be same to the message shown to user
> >> >> > screen.
> >> >> > just with "sequence of bytes" are not enough for previous
> >> >> > requirements.
> >> >> >
> >> >> > if it is handled in high level API,
> >> >> > my additional question is
> >> >> >
> >> >> > is their any mechanism for preventing secret key material changes
> or
> >> >> > other
> >> >> > sensitive cryptographic values and settings changes?
> >> >> >
> >> >> > regards
> >> >> > mountie.
> >> >>
> >> >> Hi Mountie,
> >> >>
> >> >> Yes, any scheme which relies on user agents presenting data in some
> >> >> interpreted form is out of scope for the low-level API, and /may/ be
> >> >> in scope for the high-level API. Because such schemes are
> >> >> understandably complex (eg: PDF signatures, XMLsig,
> >> >> normalization/canonicalization, etc), these are currently not the
> >> >> focus of the working groups efforts, but may be in scope at a later
> >> >> time. The current focus is on the low-level API, which does not focus
> >> >> on such application-specific issues at this time, as even a low-level
> >> >> API is a very ambitious and broad endeavor for user agents to
> >> >> normalize.
> >> >>
> >> >> I'm not sure I understand your second question, but you may find it
> >> >> answered by the Working Group charter at
> >> >> http://www.w3.org/2011/11/webcryptography-charter.html , which
> states
> >> >> that the API shall prevent or control access to secret key material
> >> >> and other sensitive cryptographic values and settings.
> >> >>
> >> >> Regards,
> >> >> Ryan
> >> >>
> >> >> >
> >> >> >
> >> >> > On Sun, Jul 29, 2012 at 10:41 AM, Ryan Sleevi <sleevi@google.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi Mountie,
> >> >> >>
> >> >> >> There were early discussions about page encodings and
> normalization,
> >> >> >> when the API included both a high-level and a low-level component.
> >> >> >> Following our recent Working Group face to face, the Working Group
> >> >> >> has
> >> >> >> resolved to focus on the low-level API and ensure that it's in a
> >> >> >> deliverable state, and then revisit the ideas for a high-level
> API.
> >> >> >>
> >> >> >> By virtue of being a low-level API, issues such as encoding are
> left
> >> >> >> to the application author. This can be seen also in the removal of
> >> >> >> DOMString (which is UTF-16) from being a valid input to the
> >> >> >> CryptoOperation.processData method, since that would have opened
> >> >> >> questions of "Is it a sequence of bytes or is it a string?"
> >> >> >>
> >> >> >> Right now, the API's interaction with data streams is accomplished
> >> >> >> via
> >> >> >> ArrayBuffer/ArrayBufferViews, which are treated as opaque
> sequences
> >> >> >> of
> >> >> >> bytes. Any further normalization or canonicalization should thus
> be
> >> >> >> done at an application layer.
> >> >> >>
> >> >> >> Does this answer your question?
> >> >> >>
> >> >> >> On Sat, Jul 28, 2012 at 5:25 PM, mountie.lee@gmail.com
> >> >> >> <mountie.lee@gmail.com> wrote:
> >> >> >> >
> >> >> >> >> Hi.
> >> >> >> >> I'm Mountie Lee from Korea.
> >> >> >> >>
> >> >> >> >> when I read http://www.w3.org/2012/webcrypto/WebCryptoAPI/ and
> >> >> >> >> searched
> >> >> >> >> archive at
> http://lists.w3.org/Archives/Public/public-webcrypto/
> >> >> >> >>
> >> >> >> >> I can not find discussion about page encodings.
> >> >> >> >>
> >> >> >> >> because WebCryptoAPI is Javascript dependent and developers
> have
> >> >> >> >> to
> >> >> >> >> consider page encodings always.
> >> >> >> >>
> >> >> >> >> many asian sites use local encodings (EUC-KR, Shift-JIS, GB2312
> >> >> >> >> ...)
> >> >> >> >> and by the page encodings,
> >> >> >> >> the javascript operation result is different.
> >> >> >> >>
> >> >> >> >> please anyone inform me the discussio thread for page
> encodings.
> >> >> >> >>
> >> >> >> >> regards
> >> >> >> >> mountie.
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Mountie Lee
> >> >> >> >>
> >> >> >> >> Tel : +82 2 2140 2700
> >> >> >> >> E-Mail : mountie@paygate.net
> >> >> >> >> Twitter : mountielee
> >> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Mountie Lee
> >> >> >
> >> >> > Tel : +82 2 2140 2700
> >> >> > E-Mail : mountie@paygate.net
> >> >> > Twitter : mountielee
> >> >> >
> >> >> > =======================================
> >> >> > PayGate Inc.
> >> >> > THE STANDARD FOR ONLINE PAYMENT
> >> >> > for Korea, Japan, China, and the World
> >> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Mountie Lee
> >> >
> >> > Tel : +82 2 2140 2700
> >> > E-Mail : mountie@paygate.net
> >> > Twitter : mountielee
> >> >
> >> > =======================================
> >> > PayGate Inc.
> >> > THE STANDARD FOR ONLINE PAYMENT
> >> > for Korea, Japan, China, and the World
> >> >
> >
> >
> >
> >
> > --
> > Mountie Lee
> >
> > Tel : +82 2 2140 2700
> > E-Mail : mountie@paygate.net
> > Twitter : mountielee
> >
> > =======================================
> > PayGate Inc.
> > THE STANDARD FOR ONLINE PAYMENT
> > for Korea, Japan, China, and the World
> >
>



-- 
Mountie Lee

Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net
Twitter : mountielee

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World