W3C home > Mailing lists > Public > public-web-security@w3.org > October 2014

RE: [Web Crypto Next] Status and next steps

From: Colin Gallagher <colingallagher.rpcv@gmail.com>
Date: Tue, 14 Oct 2014 18:21:51 -0700
Message-ID: <CABghAMjGrpzTR7P1dx5BD72JsHYZc1Y8Yb6MJq814mKbX17cPQ@mail.gmail.com>
To: ANDREAE Philip <P.Andreae@oberthur.com>
Cc: hnahari@nvidia.com, Wendy Seltzer <wseltzer@w3.org>, Siva Narendra <siva@tyfone.com>, Harry Halpin <hhalpin@w3.org>, "public-web-security@w3 org" <public-web-security@w3.org>, anders.rundgren.net@gmail.com, "virginie galindo@gemalto. com" <virginie.galindo@gemalto.com>
EMV is better than magstripe, but even given strong chip and pin solutions,
EMV systems (and by extension, anything such as Europay, Mastercard, and
Visa which would use it) are still highly and unacceptably vulnerable -
both to general hacking and malicious use or theft of personal data as well
as vulnerable to issues created by state actors, vis-a-vis TISA, FATCA, and
the like. Protocols developed to improve our woefully inadequate systems
must heal these privacy wounds and help ensure individual users can be
better protected from small-time private actors / hacks, large scale
associations / corporate theft or hijacking of data, and state actors
regardless of their country of origin (US, NY, China, Russian Federation,
N. Korea, etc.). To approach this issue, systems and protocols should be
increasingly designed to ensure more information, and more about the
information flow, can be placed within the hands of the user and managed
within user-controlled devices simply and without incident or much effort,
while also providing users of third parties and services with greater
protections in all aspects of their interactions via the web.
On Oct 14, 2014 5:47 PM, "ANDREAE Philip" <P.Andreae@oberthur.com> wrote:

> I do ponder how we integrate this work with the work of organizations like
> FIDO and how standards like EMV can be exploited.  I also wonder about
> NSTIC and the various discussions about federated credentials.
>
>
>
> The ability to solve for authentication by introducing multi-factor
> authentication and methods to replace User names and passwords seems to be
> the common goal.  The risk is with so much activity we could end up with a
> myriad of divergent and dysfunctional solutions.
>
>
>
>
>
>
>
>
>
>
>
>
> *Philip AndreaeTel*: +1 (404) 680 9640
>
>
>
> *From:* Siva Narendra [mailto:siva@tyfone.com]
> *Sent:* Tuesday, October 14, 2014 6:10 PM
> *To:* Colin Gallagher; anders.rundgren.net@gmail.com
> *Cc:* virginie galindo@gemalto. com; public-web-security@w3 org;
> wseltzer@w3.org; Harry Halpin; hnahari@nvidia.com
> *Subject:* Re: [Web Crypto Next] Status and next steps
>
>
>
> Hopefully we standardize a "pipe" and not be prescriptive on specific ID
> auth/management methods (e.g. EMV organizations, FIDO, PKCS, Derived
> credential etc). So all such relevant ID auth methods can co-exist since it
> is very difficult envision convergence of between these methods.
>
> -Siva
>
>
>
> On October 14, 2014, at 1:30PM, Colin Gallagher wrote:
>
> Briefly adding from my mobile: that integration of secure elements with
> both user-managed and non-user managed IDs, should be considered... and
> what kind of hybridized systems may emerge? (Thinking here of keybase.io,
> onename.io, BitID and similar, which hybridize web-based in-browser
> solutions, hashing into bitcoin blockchain, etc)
> Cheers,
> C
>
> On Oct 14, 2014 1:08 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com>
> wrote:
>
> On 2014-10-14 20:29, Siva Narendra wrote:
>
> To add one more point ... the work that we hope to accomplish as a
>
> > follow up to the recent W3C workshop on hardware tokens, that would
> > allow seamless integration of secure elements (with non-user managed IDs)
> > to the browsers will enable Apple Pay type convenient and secure
> ecommerce to the web.
>
>
> So let's figure out how!
>
>
> There we have a truly Herculean task!
>
> FIDO "cheated" and took the route which I have advocated years before FIDO
> started [1], namely building a standardized web-enabled security-element
> architecture which can be implemented as external tokens, pure software or
> be a part of a TEE.
> A guesstimate is that the specification-set would "only" require 300-400
> pages to match existing (non-webby) tokens.
>
> However, "there is more than meets the eye" [2], at least in my take on
> the matter we are talking about major changes in both browsers and OSes.
>
> Cheers,
> Anders
>
> 1] First public (Y2K8) document:
> http://webpki.org/papers/keygen2/keygen-all-protocol-steps.html
>
> 2] https://www.youtube.com/watch?v=0O1v_7T6p8U
>
>
> -Siva
>
> On October 14, 2014, at 11:16AM, Siva Narendra wrote:
>
> Hadi is right. Officially it is expected that visa/mc will put a ecommerce
> pricing table together that uses tokenization (like Apple Pay) that has has
> lower rates than traditional CNP ecommerce. Will it approach CP rates
> depends on ID Validation and Assurance used.
>
> Apple Pay tokens have NIST Level 4 ID Assurance because of the use of
> hardware secure element. I think iPhone 6 has a SmartMX smart card
> controller. So CP rates is quite likely for Apple Pay based ecommerce.
>
> -Siva
>
> On October 14, 2014, at 10:19AM, Hadi Nahari wrote:
>
> Rumor has it that Apple Pay might be getting CP (Card Present) rates for
> remote purchases made using iPhone 6/+.
>
> Regards,
> -Hadi
> \----------------------------------------------
> Hadi Nahari, Chief Security Architect,  NVIDIA
> M:+1.650.605.3564  O:+1.408.562.7916
> ----------------------------------------------\
> Dubito ergo mihi licet esse
>
>
>
>
>
> On 10/11/14, 10:42 PM, "Anders Rundgren" <anders.rundgren.net@gmail.com>
> wrote:
>
> Hi Virginie,
>
> During the 20Y+ we have bought stuff on the web and paid with credit
> cards,
> the method haven't changed.  That is, in spite of a billion s.c. EMV-cards
> in circulation, on the web we are currently stuck with highly inconvenient
> and (any number of times proved) unsecure CNP (Card Not Present) schemes..
>
> To me it looks like a task for your particular sector coming up with a
> proposal on how to address this pretty obvious use case.
>
> Apple have advanced the state of on-line payments by a mile in iPhone 6,
> but AFAIK it doesn't include the web.
>
> Sincerely,
> Anders Rundgren
>
> On 2014-10-10 14:57, GALINDO Virginie wrote:
>
> Dear all,
>
> A short status of where we are in the Web Crypto Next Workshop follow
> up.
>
> -As announced [1], a wiki has been set up to receive your ideas about
> the re-chartering of Web Crypto WG, taking into account the findings of
> the Web Crypto Next Workshop.
>
> -The workshop report will soon made available by Harry Halpin probably
> next week, it will be circulated on this mailing list for review during
> one week.
>
> -During  W3C TPAC meeting scheduled on 26-31 Oct [2] , there will be
> some actions to socialize the workshop findings with W3C members (during
> security related WG, during the AC representatives meeting, and during
> Wednesday Break-Out sessions)
>
> -Still during the TPAC week, Wendy, W3C security domain leader has
> organized a conversation with Web App Sec and Web Crypto chairs to see
> how we could re-charter both groups in synchronization, taking into
> account workshop findings.
>
> If you need some help to contribute, give your opinion, better
> understand direction, do not hesitate to ask question to Wendy, Harry,
> or myself !
>
> Regards,
>
> Virginie Galindo
>
> gemalto
>
> signing as chair of web crypto / chair of web security ig
>
> [1]
> http://lists.w3.org/Archives/Public/public-web-security/2014Oct/0001.html
>
> [2] http://www.w3.org/2014/11/TPAC/
>
>
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -------------------------------------------------------------------------
> -----------------------------------------
> This message and any attachments are intended solely for the addressees
> and may contain confidential information. Any unauthorized use or
> disclosure, either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable
> for the message if altered, changed or falsified. If you are not the
> intended recipient of this message, please delete it and notify the
> sender.
> Although all reasonable efforts have been made to keep this
> transmission free from viruses, the sender will not be liable for
> damages caused by a transmitted virus.
>
>
>
>
>
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
>
> -----------------------------------------------------------------------------------
>
>
>
Received on Wednesday, 15 October 2014 01:23:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:33 UTC