> 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".
So, simplified: "authentication is done using certificates", no matter if on smartcard or softokn. Isnt it? > During enrollment you may want to verify that the device you are talking to > is "genuine" or not. During enrollment, i need to know card is present and the keypair is generated inside. how can i achieve this without a pkcs#11 interface? > 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. So, our policy says: certs are always generated inside the smartcard, isnt it?. Thats not our case. We use an "official"(sorry for that) FNMT (sorry again) certs that is "imported" to the card. Anyhow, how can we control the card without a pkcs#11 interface? > 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! Nothing unusual, AFAIK. Spanish DNIe is just a securte crypto card where keypairs are not extractable/writable, generated inside and where communications are done using a secure channel. The card has a "component certificate" to show its a real DNIe. More info: http://www.opensc-project.org/opensc/wiki/DNIe > 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" :-) CISC vs. RISC. I think PKCS#11 its not so awful and will not be an epic fail. > Exposing NSS, PKCS #11 or PC/SC to downloaded browser code suffers from the > same issues. I agree PC/SC is "too low" to be ok. Softokn and other PKCS#11 crypto devices can be controlled by PKCS#11 api, and this is IMVHO the correct option to control devices. (having a well-sized/defined API). Must be a translation issue + my lack of english skills, but i dont feel you answered my previous and current question: how can i work with a smartcard without a pkcs#11 interface? -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
