Re: [Secdispatch] Call for Agenda items

[Kathleen Moriarty <[e-mail]>]

Thanks, Phil.

Please feel free to comment on Phil's proposal and drafts in a new thread.

Best regards,
Kathleen

On Thu, Jul 4, 2019 at 4:27 PM Phillip Hallam-Baker <[e-mail]>
wrote:

> I would like to present the Mathematical Mesh I have been working on. I
> would also like to arrange to meet people who may be interested in this
> work at a BAR BOF. Preferably one in an actual bar at this point.
>
> Right now, the only person funding this work is me (though I am grateful
> for the considerable amount of support from Comodo). I am currently looking
> at options to take the work further. The one non-negotiable criteria being
> that this is at root a communications system, it can only reach its full
> potential if it is unencumbered, that means anyone can use it or extend it
> without fees, licenses or permission.
>
>
> The objective of the Mesh is to make computers easier to use by providing
> a security infrastructure that works without users needing to be aware that
> they are using it.
>
> The Mesh can be used as a mechanism for managing credentials (passwords,
> private keys, etc.) for existing security applications (SSH, OpenPGP,
> S/MIME) or it can be used as a platform for developing new applications
> (end-to-end secure password catalog, secure contact exchange).
>
> One of my frustrations with the current situation in the industry is that
> we haven't moved on from cryptography developed in the 1980s. We have
> better algorithms to use in place of DES, MD5 and RSA but we haven't added
> a new capability since BitCoin added hash chains to the canon ten years ago
> and the patent on that was 1990.
>
> The Mesh introduces a new set of cryptographic techniques:
>
> *Uniform Data Fingerprints*: Think of this as 'Cryptography on rails'.
> Rails is a powerful framework because it uses the same name for the same
> field in every situation. UDF does the same for cryptographic keys.
>
> *QR Codes*: Imagine being able to scan a QR code on your bills, your pay
> stubs, tax advice, etc and get to a machine readable copy of the document
> you are reading. That is what EARLs provide.
>
> *Multi-Party Key Generation*: Weak keys have been a problem for decades
> and now we have to consider the possibility that a key was compromised by
> the device manufacturer. But keys generated during manufacture that cannot
> be extracted could be the very best keys to use (if we can trust them).
> Combining keys generated on multiple devices allows this concern to be
> mitigated.
>
> *Multi-Party Decryption*: Traditional CRM schemes use the Ford-Wiener key
> release with a key server in the cloud dispensing decryption keys to
> authorized readers. The problem with this approach is that our chief data
> confidentiality concern is a breach of the cloud, i.e. the key server.
> Separating the decryption function into two parts and requiring both to
> participate enables a key server to control decryption of data without
> being able to decrypt.
>
> *DARE Envelope*: This is a new PKCS#7 type format built on JOSE which
> provides the hooks needed to support the Multi-Party Decryption scheme DARE
> Container.
>
> *DARE Container*: An append only log format supporting incremental
> encryption and authentication. If I am talking to VC, I might even call it
> a block chain.
>
> *Shamir Secret Sharing*: Personal Escrow of the user's keys is supported
> with up to 16 shares and a quorum of 1-15.
>
> There is quite a bit more to the system but it remains remarkably compact
> and especially so considering the scope of its capabilities.
>
> One innovation that addresses a current concern is that Mesh Accounts are
> the property of a user and not the service provider. So if I want to change
> my service provider from example.com to example.net, I can do that at any
> time of my choosing and I don't need example.com to co-operate of give
> permission for the transfer.
>
> The trust model does have a role for Certificate Authorities but this is
> optional and limited to the discovery process, CAs are not ongoing
> participants in every transaction. Direct exchange is also supported via
> both an in-person model (e.g. QR code exchange or bump phones) or remotely.
>
>
> All the reference code is MIT License and copyright Comodo Group (to
> Version 2.0) and Comodo Group and myself (3.0 on). The tool chain used to
> build the system is MIT License and my copyright. I have attempted to avoid
> encumbered technology and I am not aware of any valid claims on the current
> specs but make no warranties in that regard.
>
>
> I have submitted all the documents as Internet drafts but there is a
> catch, I am writing the documents assuming that the transition to HTML RFCs
> is going to happen. So you can read them as plaintext drafts if you insist.
> But the HTML documents have diagrams and use superscripts and subscripts
> for the math rather than X_A which makes them a lot easier to read.
>
> The architecture draft provides an overview of the project:
>
> http://mathmesh.com/Documents/draft-hallambaker-mesh-architecture.html
>
> The following drafts are nearing completion. I am currently working on
> getting the worked examples from the running code worked in:
>
> http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html
> http://mathmesh.com/Docume…/draft-hallambaker-mesh-dare.html
> http://mathmesh.com/Docu…/draft-hallambaker-mesh-schema.html
> http://mathmesh.com/Documents/draft-hallambaker-mesh-cryptography.html
>
>
> I might have the protocol specification available by Montreal but that
> might slip.
>
>
>
> On Wed, Jun 26, 2019 at 2:55 PM Kathleen Moriarty <
> [e-mail]> wrote:
>
>> Hello,
>>
>> If you wish to present at SecDispatch in Montreal, please send a message
>> to the chairs and preferably to the list with the draft link that you plan
>> to present.
>>
>> Thank you.
>>
>> --
>>
>> Best regards,
>> Kathleen
>> _______________________________________________
>> Secdispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/secdispatch
>>
>

-- 

Best regards,
Kathleen