Dear "helpcrypto", now it became a little bit messy because I'm talking about principles while you are talking about specific interfaces like NSS, and PKCS #11.
> 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? None of the popular cryptographic APIs support container attestations. None of the PKIX enrollment protocols support container attestations. Container attestations must be performed at the APDU-level since E2ES cannot be "abstracted". Redhat supports container attestations (aka Secure Messaging) in their "DogTag" card management product. This part does not rely on PKCS #11. >> 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. Are we actually talking about the same thing here? I'm talking about exposing cryptographic APIs to code running in an arbitrary web page. This is what CertEnroll does and that is an *extremely* bad idea. Compare this with HTTPS which can be invoked from any page without exposure of a single cryptographic method. That's a good system. I still don't understand the Spanish use-case and particularly not why you need card-level Secure Messaging for signing data. I guess it is also about the server authenticating to the card? Anders On 2012-04-18 09:16, helpcrypto helpcrypto wrote: >> 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: > >> 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
