On 2012-04-17 14:14, helpcrypto helpcrypto wrote: >> It was for example suggested that PKCS #11 should be exposed as a >> JavaScript object. I think that is downright ridiculous idea, >> almost as bad as: http://www.sconnect.com/FAQ/index.html > > Let me expose two user-cases where i think that will be helpfull (and > maybe the only option). > > -Web page that allows company users to request a certificate WITHIN > company smartcard: > User inserts smartcard, click request, connection to pkcs#11 is > made, if card present, all the operation can be done. > > Otherwise (current), request is done "somewhere". If a card is > present, a dialog (where the user can mistake and select the bad > crypto device) is shown, otherwise is requested on softokn. We dont > have any control if certificate is on card or softoken :( > > -I want to establish a secure conversation between my server and an > smartcard like european ids, knowing im talking with a valid secure > device (like Spanish DNIe secure channel)
Although E2ES (End-to-End-Security with respect to the *container*) is actually my line of work (http://webpki.org/papers/keygen2/sks-api-arch.pdf), I don't understand why you would use it during signing or authentication. Yes, TLS-client-cert-authentication is also E2ES but it works "one level up". During enrollment you may want to verify that the device you are talking to is "genuine" or not. After enrollment you do not need to repeat this because the policy expressed though the enrolled certificate should implicitly or explicitly provide this information to the relying party. There may surely be something in the Spanish scheme which I don't know about, but I suspect that whatever it may be, it is probably a bit "unusual" :-) Feel free enlighten me! > >> Making Firefox compliant with Windows and OSX keystores is IMO an >> entirely different task. > > Indeed it is. Good. > > > So, IMHO there are 2 milestones: > -Make NSS work with CryptoAPI/Keychain / Linux? > -Export a PKCS#11/15 javascript API to communicate with any > cryptographic device. (This+OpenSC=everything working everywhere!) > > Anders, I'll like to hear why you consider that (PKCS#11) a "downright > ridiculous idea". Microsoft's "CertEnroll" solution exposes quite a bunch of sensitive APIs. This creates an awful lot of security and privacy-related dialogs which no normal user can possibly understand. I call it "Epic Fail" :-) Exposing NSS, PKCS #11 or PC/SC to downloaded browser code suffers from the same issues. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
