Re: Feedback, comments and so about WG Web Cryptography API

> The current Web Cryptography Working Group charter (
> http://www.w3.org/2011/11/webcryptography-charter.html#scope ) specifically
> details as out of scope "functions in the API that require smartcard or
> other device-specific behavior".
>
> As such, this API does not and should not describe any smart card specific
> behaviour, including PIN handling. While the current low-level API strives
> to be a generic enough API that conforming user agents may be able to
> implement atop existing cryptographic APIs, including those which handle
> smart cards, any behavior that is specific to smart cards is implementation
> defined and will not be specified.

I understand smartcards are "out of the scope", but just want to point
that sometimes you want keys be generated on specific devices.
In fact, PKCS#11 Standard is not only for smartcards, but for software
too. So, maybe smartcards are out of scope, but pkcs#11 is not.
Anyway, you have been very clear at this point.


> The handling of certificates is defined as a secondary API feature, and thus
> not the primary focus of the deliverables. Within the current Use Cases
> Editors Draft ( http://www.w3.org/2012/webcrypto/wiki/Use_Cases ), such
> functionality is listed under Miscellaneous.
>
> The current draft has not yet defined key discovery, although it has been
> discussed. The API currently specifies keys, and does not define any
> certificate metadata associated with keys, either for discovery or for
> future use.

Ill wait to see future development. Thanks


> Such support is not addressed by the charter, and therefore likely out of
> scope. It's possible to implement an ASN.1 parser in JavaScript, and it is
> possible to implement a basic PDF parser in JavaScript. Thus, it should be
> possible to combine such functionality with the defined low-level APIs to
> provide the desired behaviour.
>
> Requiring that conforming user agents specifically implement PDF signatures,
> expose OCSP or timestamping APIs, or implement XAdES-XL directly to content
> script is a very unlikely proposition for this WG, as chartered.

The reason why we use Java is to be able to provide a better and
common user experience, as the same time as _friendly_.
If the signing method you are providing will be so low-level to show
something like "you are going to sign <data>...end-users love
xml...</data> Enter the PIN", then ill continue using -killing myself-
Java.

The reason why i asked for complex methods like pdf/xades was to let
the user truly "preview" whats going to be signed, in a human readable
way.
People has to know what they are signing, and a XML is definetively
not the correct way.
I dont know if i explained the problem clearly. Please, discuss if you
find this usefull.


> Please see the current editors draft,
> http://www.w3.org/2012/webcrypto/WebCryptoAPI/

Added to my weekend.


> The low-level API makes no specifications about the underlying data format.
> It processes it as an opaque stream of bytes.
>
> Applications that require normalization or specific encoding rules will need
> to do so at the application layer. It's also possible that there will be a
> high-level API that provides normalization rules and a canonical encoding.
>
> See also http://dev.w3.org/html5/spec/single-page.html#atob , which
> applications may use for their own canonicalization purposes.

That was i was suggesting, byte [] is the correct way. Thanks


> Because the current Editor's Draft makes use of the ArrayBuffer, it should
> be possible to use the File API, http://www.w3.org/TR/FileAPI/, to support
> streaming reads of a File or Blob from content script, and then use the
> CryptoStream.processData() interface to append to the ongoing operation.

Going to do the same on my code. Thanks.


Thanks again for your answers, ill be very interested in future
development of the document.
Regards

Received on Tuesday, 24 July 2012 07:21:41 UTC