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

Hi Helpcrypto,

I hope you don't mind some non-WG comments.

On 2012-07-20 08:29, helpcrypto helpcrypto 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

Generally the concept of batch and the web do not fit well but a signature scheme
may allow upload of multiple documents to be signed in one step.  There is also
the concept of PIN-caching which is an attribute of a key.  PIN-caching IMO, though
requires that you are in the same session which fits your code example.

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

This is indeed a clear omission in most signature schemes. I had this from
the very start in my WASP proposal.

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

Key generation in smart cards is out of scope for the WG.  This is OK
since there is no mechanism in NSS or PKCS #11 to actually say "hey,
this key was created in a smart card" which is necessary and is already
featured in other endeavors like Google's Wallet.

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

Yes, this is a *REQUIREMENT* and it has been voiced by me more than once.

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


See comments on smart card key-gen.

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


thanx,
Anders

PS Why are you so secret? Other people in this community are not DS

Received on Friday, 20 July 2012 09:20:17 UTC