Feedback, comments and so about WG Web Cryptography API

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


##########
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.


##########
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.


##########
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


##########
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.


##########
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")


##########
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.


##########
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)


##########
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?




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.

Received on Friday, 20 July 2012 06:34:07 UTC