On Mon, Oct 14, 2019 at 6:03 AM Eliot Lear <lear@xxxxxxxxx> wrote:
It’s a fun question, and there is (at least to me) an obvious answer. In the good old days we used to have key signing parties at the IETF, and it would be possible for people to attest that I am indeed me and you are indeed you. That way, at least you could see by people’s signatures whether or not there was someone who signed their key who you knew.The problem is that the UX would have to keep up with that. I’m not sure it’s quite up to the task.Eliot
What if we could have an automatic key party when people register?
This is not something the Mathematical Mesh currently supports but it is certainly one of the things the infrastructure is designed to support. And as it happens we are having a MATHMESH BOF in Singapore.
The goal of the Mesh is to make computers easier to use by making them more secure, which demands a really low level of demand on the attendee. And here the point is not to only provide a feature for IETF use, the point is to provide a mechanism that can support validation of people within a PKI.
The TLDR here is: QR Codes, Blockchain, mobile app, kiosk in registration area. Needs graduate students willing to write some code and do integration.
I just recorded a video giving an outline of the design but it will be a while before I get round to editing it. Here is a brief summary of the proposal.
Objective: Establish that a person attended IETF without necessarily verifying the identity of that person with respect to government issued credentials.
1) Assume that people have a Mesh Client Application on their mobile device which has the ability to scan QR codes.
2) Assume that there is something that looks like a picture frame in the registration area. To claim attendance at the IETF, Alice (the attendee) opens up her Mesh Client App and scans the bar code. She is told if she were successful or some error occurred but that is the extent of the interaction.
This interaction is of course merely one particular specialization of a generic interaction for exchanging contact information via a mobile phone 'bump'. This is something we should have established as a standard long ago. One of the major Internet companies got very excited about this a few years back. Unfortunately the excitement took the form of buying a company 'to make it happen', pulling the existing app from the stores and then losing interest.
So what happens at the protocol level?
0) The application has a public/private key for signing that is credentialed under Alice's personal Mesh
1) The QR code contains UDF of the form
This changes at regular intervals so each attendee will register to a different code.
2) Following the process described in:
This is transformed into the following URL and resolved.
The returned data is a DARE envelope. This is decrypted using the key EDX6-OS5A-D4LO-IPT5-EVOR-4QFW-AZWE-4Q and the Message Authentication Code verified.
3) The decrypted document is a JSON encoded structure yet to be defined that gives the client a Mesh Service Account identifier, (registration@xxxxxxxxxxx), a PIN code (NC6B-EYP6-O3JR-54HY-IE45-FOUU-TIPQ) and an indication this is a notarization event.
4) The Mesh Client makes a contact notarization request to registration@xxxxxxxxxxx. This is signed by Alice's device key
5) The contact notarization request is enrolled in the example.net notarized log. Which is a DARE Sequence verified by a Merkle Tree. This may or may not be made public.
[Optimizations are possible here, the picture frame doesn't actually need network connectivity. When it is turned on the first time, the admin scans a QR code which causes a shared secret to be passed to the example.net service and this is used to generate the QR code and other data via a counter and a KDF.]
So what do we get from all this?
Assuming that the example.net notarized log is cross notarized with other authorities, the work factor for defection increases to an infeasible level very very quickly. So Alice can establish that her phone 'bumped in' at the registration desk. We can have separate discussion of how public this should be and whether we want to have binding factors, zero knowledge and such (more grad student projects).
The amount of validation we get from a single unverified bump in is small. But if we do it every meeting, it can rapidly mount up. Someone who has bumped in at a dozen IETFs... that alone is pretty compelling that there is a person there, not a bot. Someone who have bumped in at a variety of different conferences, RSA and IETF and ICANN, much stronger still.
Now assume everyone is using the Mesh, it is a part of the Android and iOS operating systems, etc. We can make bump-in the default means of registration for the conference. Instead of being a standalone display in a picture frame sorta thing, the QR code generators are linked in to the conference reg system so that when I bump in, my badge starts printing or it appears on the console of the person with that box of badges.
And one more thing,
One of the things that irritates me about public events is that everyone is on their phone taking not very good pictures. And they only get one set of pictures from one angle at best. What if we could share and it was painless to do so?
When I bump-in, I could collect a URL for a Web site with photos for that event that people have uploaded. And I can upload my own (if I choose). So we get the gift exchange going.
And of course, since it is the Mesh underneath, we can exchange encrypted documents. I have been thinking a lot about the 'revenge porn' issue of late and think I have some answers there.
