On Tue, May 3, 2022 at 12:47 AM Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote:
> On 3 May 2022, at 12:24 am, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> I'm not convinced that that's the (only or even most important) reason, or that it's even true. From my perspective there have been several barriers to adopting S/MIME and/or PGPMIME, e.g. lack of MUA support, lack of email domain CAs and support for them among root CAs, lack of a well known and trusted set of root CAs such as exist for the web (it's not clear that they should should be the same set), lack of a standard key discovery mechanism, and (mostly I suspect) lack of mindshare.
>
> When there are multiple barriers to solving a problem, any one of those problems can become an excuse to avoid solving the other problems.
Key distribution and discovery isn't the fatal problem, the fatal problem
is that encrypted email is unusable once received and stored.
Until encrypted email is usable (**search**, long-term signature validation,
personal private key rollover, ...), all the key distribution tech in the
world won't make it worth adopting.
PHB's mathematical mesh might come closer to addressing the key distribution
problem, but then we'll still have all the hard MUA issues. Someone will have
to want to build MUAs that really solve the usability issues. I don't see that
happening in a space dominated by cloud web mail providers, not sure it lines up
with their business models...
I have the perfect solution to private key rollover - my keys never expire. I don't allow use of weak crypto. If Ed448 or X448 can be broken at all, rotating your keys once a year won't help.
What I do instead is to partition the keys so that every device has its own key set. For decryption, the use of the keys can be withdrawn if they are issued as threshold shares instead of a direct key.
So my signature keys never expire. The part of the Mesh I am currently working on is the callsign infrastructure and cross-notarization scheme which has the effect of locking all the user's personal append only logs together so that if Alice is validating a signature, Alice becomes the root of trust for that process.
So Alice has an append only log with a hash chain (its actually Merkle Trees, but for simplicity, chain)
Every day, Alice signs her final hash value and send the resulting notary token to her MSP which enrolls the token in its own log.
Every day, Alice's MSP signs its final hash value and send the resulting notary token to Alice to enroll in her log.
Every hour, every MSP performs the same cross notarization with the Callsign registry.
So when Bob signs a document, he adds an entry to his personal append only log. This is cross notarized with his MSP which cross notarizes with Alice's MSP which cross notarizes with Alice.
As a result, when Alice comes to check a signature, she can check the signature value against a proof chain that is rooted in her own personal append only log. Alice thus knows that the signature was created on that day and with which key.
[It doesn't need to be the callsign registry that acts as the synchronization point, nor is it necessary for there to be only one. The point is that all the personal trust logs mesh together. It is impossible for any user to defect without detection. There is no reliance on a trusted third party. There is no proof of work, waste, there is no Ponzi coin]
OK so search is hard. The Mesh system is entirely end to end and the service has no visibility. In fact, the service doesn't even know the account name the user uses. The only thing the MSP knows is the fingerprint of the user's profile signature key.
In order to do search then, a search index is going to have to be compiled on at least one of the user's devices. Depending on the user's security concerns, it might be acceptable for the user to have a device that has her account encryption key decrypting every message, compiling an index and uploading it to the MSP.
Failing that, devices are going to have to do search locally. But that might not be quite as hard as it appears because unlike SMTP, Mesh Messages are limited to 32KB. All the images, videos, etc. are passed as external attachments. If there is a looong email message, the text part is also an external attachment. But even so, I only have 35GB of gmail and much of that is from mailing lists and an even greater amount is clutter. The text parts of my emails are probably less than 1GB and my iPhone can easily handle that.
So in summary, yes search is a hard problem and I do not currently have code. But it is certainly not an insoluble problem.
Again, going back to the Web. One of the reasons the Web worked was that we pushed the search problem out to later on.
Most of the searches I do on my emails are actually trying to find emails I sent or received and the search terms are limited to the subject line. Text search is actually a poor way to do what I am trying to do most which is to find invoices for orders I placed in the past so I can order spare parts or make a repeat order. And again, the sheer amount of junk mail makes it a lot harder.
Tim B-L was really onto something when he was talking about the Semantic Web. The Web would be a heck of a lot more powerful if there was some easy way for the machine to recognize a mail message as an invoice or delivery note so that my house management system knows that I just bought an XYZ fridge and it will need PDQ filters every 6 months.
But maybe the missing link in that workflow was security and the lack of a decent security base was the reason we never got round to build the semantic components on top.
