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

On Thu, Jul 19, 2012 at 11:29 PM, helpcrypto helpcrypto <
helpcrypto@gmail.com> wrote:

> A few days ago, David Dahl just appeared (like a ninja) on mozilla
> dev-tech-crypto to show the progress you actually have working on Web
> cryptography API, and i will like to give some more feedback trying to
> help as much as i can.
> I sorry for any mistake, typo or wrong talking, as I'm not English
> native. I also apologize if i mix could/should/must...i tend to write
> too fast without thinking twice. I'll do my best.
>
> To introduce myself, lets say i work for a university developing
> client components, like pkcs#11 libraries, an applet for client
> signature, etc.
> I do not work for mozilla, google or other big companies like that, so
> probably i don't have the skills needed to join the WG, neither i know
> if i can/should.
>
> IMHO, the needs we are facing are very frequent and happens also to
> people working for ministry, gov agencies and other e-admin
> organizations, so wrong or right, they could be considered as a valid
> example and maybe discussed
>
> Please, don't hesitate to contact me for anything you need and
> consider. I truly believe you are working hard on this "for the
> sake/glory of the crypto community". I really thank you the effort.
>
>
> ##########
> Multiple PIN request are boring and tend to become dangerous. The same
> key can be used for many signature operations.
> A PIN objective is to protect some valuable object, if you ask more
> than once the PIN, the user tend to write the PIN everywhere, loosing
> the security value it provides.
> In our organization, "the boss" usually signs a lot of documents each
> day, and he _cant_ write the PIN once for each operation.
> Considering the previous statements, i think a batch approach must be
> possible:
>
>     signInit () //where you specify the sign type and cert/key to be used
>     signAdd()  //to add an item to sign
>     ...
>     signFinal() //to start the signing process
>

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.


>
>
> ##########
> Is the user signing a document with the correct cert?
> Sometimes, like when doing a challenge for authentication, we want the
> user to select a "valid"/specific certificate.
> For example, if he user has a personal and an employee certificates.
> How can we get sure he doesn't mistake or be sure the operation ended
> as we expect?
> Considering the previous statements, i think signInit operation should
> allow "certificate selection filter" and should return the selected
> cert (including public key).
>
>     cert=signInit({cert:{issuer:"TERENA"}});
>
> Of course this involves a privacy risk, as certificates can contain
> even the personal address of the user (although they shouldn't!!!)
> Anyway, there must be a way -server side- to know which cert the user
> used to sign, otherwise the signing could be valid, but not policy
> compliant.
>

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.


>
> ##########
> Are the request certificate mechanisms user-proof?
> As discussed in the past on dev-tech-crypto, we (and i can tell, many
> others) have smartcards in our company.
> We want the user to generate the certificates within their cards, and
> use them from there.
> Is quite frequent, users tend to click in the wrong button, and select
> their personal certificate (for taxes) instead of the gov employee
> one. (They are instructed not to do so, but accidents happen)
> It could be nice to be able to select the smartcard/token from where
> the keys are used:
>
>     generateKeyPair("tokenname",key-specs)
>
>     singInit("tokenname")
>
> Where token name could be "NSS" for the local database, or "MYpkcs#11"
> for the registered name in secmod/pkcs#11 modules.
> This could help a lot developers when working with smartcards, as the
> user will not have to click, but the "site" selecting for him.
> If the token is not present, just a TOKEN_INVALID error will be OK.
>

This is specifically out of scope, as it requires smart-card specific
behaviour. It's also unlikely to be implemented, given the inherent
security concerns related to the web platform.


> ##########
> There can be many complex sign algorithms, like XAdES-XL or things
> like that which could need a more complex API, providing timestamp
> authorities or OCSP validation.
> Also, it will be great to have PDF signatures which will lead to
> library dependencies
>

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.


>
>
> ##########
> Things can go right, wrong or simply go.
> That's the reason why i usually prefer a 3 event callback system,
> rather that "onEvent" focus.
> Having an onProgress event can be used to notify final app. eg: a
> layer on the client application shows the signing is at 50%.
> Considering the above, the callbacks should be:
>     onError
>     onProgress
>     onUpdate
>
> Of course, ALL methods should be async, to avoid browser hangs.
> IMHO, having "high level" (onEnd) and "low-level" (3 callbacks) APIs
> will make the api CISC, where we all know RISC is much better :P
> Remember: One ring to rule them all. The "low-level" is simple enough.
> As doing a hash of a 50MB document is not so light, hashing should
> ALSO use callbacks and be async.
>

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



> ##########
> A signature is a signature, no matter where you are.
> That's the reason why, if you live on Korea, Cambodia or USA, we just
> sign base64 strings.
> We have found problems to verify signatures made on Chinese where the
> text was encoded in i-don't-know-the-encoding-they-use.
> Since we use base64 strings, everything is signed properly.
> Considering that:
>     signAdd("data") ---> signAdd("A9A6B4A6")
>

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.


> ##########
> There's no need to specify public & private keys when signing.
> A public should be always linked to a private, so sign operation could be
> like:
>     cert=signInit()
>     signAdd ()  //it automatically use the previously selected keys,
> like how its done in C_SignInit on pkcs#11 standad.
>

Please see the current Editor's Draft, specifically
http://www.w3.org/2012/webcrypto/WebCryptoAPI/#WebCryptography-interface-low-level


> ##########
> When generating a key, the strength should be customizable.
> For legacy reasons, some smartcard cant handle 2048 certs, so we just
> generate 1024 keypairs.
> Considering that:
>     genKeyPair(RSA, 1024)
>

Please see the current Editor's Draft, specifically
http://www.w3.org/2012/webcrypto/WebCryptoAPI/#WebCryptography-interface-low-level


> ##########
> Big document issues.
> In our company we need, from time to time, to sign "BIG" pdf documents
> (like >10MB PDF), and that usually almost-kill the browser.
> When the users selects a PDF file to sign, how the user should expect
> the signature?
> In our experience the following code
>
>     //js client code
>     var signData=signFinal()
>
> crashes when signData is big enough, that's why actually we do something
> like:
>
>     //signature component
>     while(!dataEnd)
>         appendMoreData(htmlInput)
>
>     //js client code
>     var signData=htmlInput
>
>
> In the past days i have been trying to figure "how to make work" the
> following:
> user gives:
>     data:base64StringToBeSigned
>     url:urlFileTobeSigned
>     file:localFileToBeSigned
>
> user expects:
>     if the data is small (<4MB), i can return data
>     if its big, but not stored on server, a file is returned
>     if the signed document must be stored serverside, i can return url
>
>     data:signedBase64String
>     url:urlWhereSignedDocIs
>     file:localFileWithSignedData
>
> What do you think about that?
>

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.


>
>
> Well...i think is enough by now.
> Probably i missed a lot of things, but i hope that will help you
> making a better standard which could let me escape (i pray for that)
> from java applets and lovely MSCAPI.
> Thanks a lot for your patience and time, regards.
>

 This API does not seek to define a smart card provisioning API, which have
historically been what those APIs have been used for.