Re: any discussion thread for page encodings?

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
>

Received on Sunday, 29 July 2012 07:40:21 UTC