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

On Tue, Jul 24, 2012 at 12:11 AM, helpcrypto helpcrypto
<> wrote:
>> The current Web Cryptography Working Group charter (
>> ) 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.

Correct, many APIs use concepts such as "providers" to abstract out
the specific notion of devices, although typically such work is
semantic more than functional - there is typically only one or two
software providers, and the rest are all abstractions around hardware.

Unfortunately, such abstractions are not consistent between various
low-level APIs such as CryptoAPI, Cryptography Next Generation (ie:
BCrypt*/NCrypt*), Keychain Access, CDSA, PKCS#11, JCA, etc. Because of
this, trying to find a common, unified way to expose these to
applications, in a way that such differences are presented
consistently, is unfortunately a fool's errand.

The current Editor's Draft proposes to refer simply to keys, which are
collectively amalgamated into a single logical store or provider. The
keys themselves may be backed by any number of implementations, both
software and hardware, and may have any number of restrictions imposed
on them because of this. However, from an application's perspective,
keys are keys.

While this will not satisfy the needs for those who wish to interact
specifically with smart cards, it represents a balance between
functionality, cross-implementation compatibility, and security.

>> 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 ( ), 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.

Yes, such a use case has been part of discussions related to a
high-level API, and have been incorporated in the use cases document
as secondary features. It is helpful to know you would find value in
such an API.

However, please realize there are a host of non-trivial security
issues with such a workflow. Such schemes, whether implemented as
custom browser plugins or as Java applets, have been victim to a
number of attacks over the years. Designing an API that is both
functional and secure that can meet these needs is thus no trivial
task, and the current effort has instead been focused on finalizing a
low-level API that, in many senses, may be easier to implement and
deliver as a work product of the Working Group.

>> Please see the current editors draft,
> 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 , 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,, 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 Sunday, 29 July 2012 02:02:48 UTC