Hi. I'm from Korea. let me comment something more. for signWithUserConfirmation as I know, that requirement was raised because of regulations of some countries. it is UI specific function and need some fixed UI (already mentioned spanish DNIe) I think we need some control for that with CSS style the very important concept is "the content that user is viewing on the screen" must be same to sign source.
for the encodings many asian countries has it's own local encodings EUC-KR at Korea, Shift-JIS at Japan, GB2312 at China those are not unicode. even with these encodings, I think DOMCryptAPI must be work. base64 encoding is one of good considerations but that is not so user friendly. for smartcard supporting I think PKCS#11 is the best choice I can think. the key pair(public and private) will be stored at secured browser keystore (the existing) the browser keystore can be connected to smartcard with PKCS#11 interface. even in Korea, Smartcard emulated USB token is widely spreading and P11 is becoming base technology for the sign formats my personal interest is XMLDSIG which is W3C standard. for the user environment in Korea, the government's basic understanding is "user environment can be easily compromised" before going to production, followings are required to be checked. - resistant for Key-Logger : normally onscreen keyboard is used. but in future more good solutions can be used - resistant for virtual memory hacking : even with SSL communication, the private information is searched in virtual memory area (like windows pagefile.sys). the DOMCryptAPI must have memory cleanup logic. --------- in Korea, binary plugins (ActiveX or Flash) are widely used for generating signature or managing key pairs. I hope this project can be good replacement of current binary plugins. regards mountie. On Wed, Apr 25, 2012 at 5:12 PM, helpcrypto helpcrypto <helpcry...@gmail.com > wrote: > Just some commets you could ignore :P > > As said before, i dont know if you have considered smartcard. > These, (as discussed in > https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/hNS32Zhz9gw > ) > could have some other needs. IMHO, a lot of discuss yet to come. > > I have experienced some issues regarding to encoding. > A page encoded in ISO send some data to a page encoded in UTF-8 which > signs...then, verify could not match. > So we decide to use base64 binary encoding for all operations. I think > "plaintext" maybe its not the best option (or maybe im wrong) > > <half offtopic> > Its being discussed on the other thread, but just to let you know, > actually, theres not a way for knowing if Keypair generation is made > on softokn or smartcard, and that lead (in our company) to some > problems. I think something must be done about this. > I agree with Anders Certenroll could be (*IS*) evil, but if an > app/site developer what to use an specificsmartcard, perhaps he should > be able to know if that smartcard is present... > </half offtopic> > > Regarding signWithUserConfirmation, you should consider some devices > (like spanish DNIe) show their own window, which "you cant control" > when going to sign. Anything i can do for you regarding this, just > tell me. > > As i can do RSA512 or RSA1024 with a 2048 RSA key, and like someone > suggested, i think a default mechanism/algorithm (if not specified) > should be enabled, but developers should be able to choose one... > > Will be possible to create a more complex sign-formats, like PKCS#1, > PKCS#7, XAdES, XML, PDF...? > > Maybe i didnt understand it well, but Im REALLY concerned about your > public key handling. IIUC, a site could get access to the public key, > and i dont waht that at all. > My public key can contain my name, identity card or even my > address...i think this IS a privacy issue. > > Public or private keys should be a reference/handler, not the keys. > Maybe you could do something like this: > > -invoke selectCertDialog and keep an internal reference of selectedCert. > -do operations like hash(sign) form js, without having the public cert > (only internal has the reference) > -to operate with another key, invoke selecCertDialog again > > Thanks a lot four your work, Im sure more question should come... > -- > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > -- Mountie Lee Tel : +82 2 2140 2700 E-Mail : moun...@paygate.net ======================================= PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
