On 2012-04-18 13:06, ianG wrote: > (lo-pri interest only requests) Short return then :-)
> > On 18/04/12 20:00 PM, Anders Rundgren wrote: >> On 2012-04-18 11:04, helpcrypto helpcrypto wrote: > >>>> 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 :-) :-) > > > Hmm... I haven't read your cocktail books above, but do you have a > minimalist recipe? What's a Secure Message? In explanatory terms. In the SC-world it is a secure channel between "something" and the card. > > ... >>>> 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"? > > > (to me, that question makes no sense. users can't talk to smart cards. > Only smart card readers and programs can. So what smart card reader > and what program is doing this? A dumb smart card reader and a browser, > following Javascript instructions from a website? That'd be game over...) Exactly my point. Microsoft's "solution" to this is annoying the user with dialogs like "this site wants enumerate your keystore, do you accept?" > ... >>>> 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. > > curious ... (smart card) money products also work this way. That is, at > its base layer, peers talk with secure messaging. Once you've got that > layered in as the core design, the rest is easy (handwave handwave)... > they problem is that most designs don't get that right, and struggle. > > Although, maybe I'm reading more into "secure message" than is meant. > >> 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. > > > Well, using my view of a secure message, the conceptual browser can't be > a peer. So all it can do is do packet routing. That's exactly what it does in the document above. > But, real-world browsers don't do that, they pretend to be the only > peer, and that's where the trouble starts. > > > > iang Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
