----- Original Message ----- > From: "helpcrypto helpcrypto" <helpcry...@gmail.com> > To: "David Dahl" <dd...@mozilla.com> > Cc: "dev-platform" <dev-platf...@lists.mozilla.org>, "mozilla's crypto code > discussion list" > <dev-tech-crypto@lists.mozilla.org> > Sent: Wednesday, April 25, 2012 3:12:23 AM > Subject: Re: Feedback on DOMCryptInternalAPI > > 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.
Supporting smart cards in the spec and first implementations is not a goal, however, I think a lot of the base work we are doing will help in a future iteration. For instance, I hope that this Gecko 'internal API' will help extension and browser developers to experiment with smartcards, crypto keys, etc. > > 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) > Are you saying you base64 encode the data to be signed before the signature is created? > <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. > sounds like some research to do. thanks. > 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... > agreed, however, we will have minimum keybits and constraints on the algorithms allowed. > 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 key as a privacy risk? I don't imagine we will have an address bound the the public key. > > Public or private keys should be a reference/handler, not the keys. Private keys will never be visible to content, only a keyID. Again, this thread is really about an internal API specific to Gecko. Regards, David -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
