On 2012-04-18 11:04, helpcrypto helpcrypto wrote: > On Wed, Apr 18, 2012 at 10:03 AM, Anders Rundgren > <anders.rundg...@telia.com> wrote: >> 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. > > Ok. Rather than discussing technical or theorical point of views, i > think we could start focusing on "what the user need and how can we do > it" possible(design/implementation). > >>> 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. > > Using CryptoAPI you can select which CSP to work with, and a CSP can > point to a specific smartcard. > If the keys are generated inside the card i dont need a PKIX > enrollment protocol that support anything special, cause im sure the > keys are generated on the right place.
My scenario is a billion+ community who haven't a clue what a CSP is and never will. They may not even know what a certificate is! A CSP-solution doesn't give the issuer any information about where and how a key was generated. The same goes for NSS, JCE, and PKCS #11. >> Container attestations must be performed at the APDU-level since >> E2ES cannot be "abstracted". > > I dont understand that. See section 9.5 of: http://forja.cenatic.es/docman/view.php/160/684/cwa14890-01-2004-Mar.pdf I have taken another path than ISO/CEN but both concepts stem from the same root: http://openkeystore.googlecode.com/svn/trunk/resources/docs/Efficient-Provisioning-of-Complex-Structures-Over-Unsecured-Channels.pdf As can be seen from the documents, Secure Messaging isn't something you could bring up on a typical cocktail party :-) :-) > Again: lets try (both) to leave the theorical/technical, and think in > what the user needs. > >> 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. > > Consider: I want a user to be able to request a certificate on our > company smartcard. > Is that an "*extremely* bad idea"? If it works like "CertEnroll" or "SConnect" it is indeed an extremely bad idea because it exposes the card to accesses by untrusted parties. > If you think is not, lets focus on the problem itself: how to request > a certificate within a smartcard > If you think is it...could you tell me why? > >> Compare this with HTTPS which can be invoked from any page without >> exposure of a single cryptographic method. That's a good system. > > I really this understand this. You think "a protocol" is the solution? Almost. I started years ago with a protocol and later realized that secure messaging must be a part of that. However, given the weirdness of smart cards, I found that you would also need a carefully matching container in order to ever get it supported inside a standard browser. >> 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? > > Seems the DNIe doesnt help to clear the problems im having. Forget the > example and try to focus on the "detect anc work with the smartcard" > issue. Regards, Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
