On Mon, Sep 9, 2019 at 7:33 PM Bron Gondwana <brong@xxxxxxxxxxxxxxxx> wrote:
I last saw something like that at the BIMI BOF in Prague at IETF104. Not quite "the worst idea in the history of the IETF", but a very strong and emotional "this is a horribly bad idea and I strongly oppose the IETF doing any work in this area and I will fight you to the death and die on this hill".
I missed the BIMI BOF but that statement had me really thinking 'we should do it!'. Nobody has ever told me something like that without them turning out to be hilariously wrong.
So I found the spec:
It is a real pity that I was not there because this is precisely the problem that I originally called the meeting that resulted in CABForum being formed for. If anyone has IPR concerns, they will find prior art in my book The DotCrime Manifesto (2008).
The IETF has in fact already published RFCs that do precisely this. See RFC 3709:
OK, so DMARC is slightly different method of delivery but we have all the technical stuff done modulo uninteresting arguments over encoding. The hard part has always been to specify the validation processes. If you want to put a brand on an email you are going to have to validate it and that means you are going to either have to adopt the strategies we developed for VeriSign Class 3 in the 1990s or re-learn them.
If people would like to do this, the way that was discussed at CABForum was to engage the WIPO Trademark Registry established under the
Madrid Protocol. So basically, you perform Extended Validation criteria as per normal and then compare the mark with the registration and establish proof of right.
The division of work on such a scheme would have to be IETF restricts itself to the technology and leaves the certificate policy issues to CABForum. Because that is the division we have established.
So yes, we could actually do the proposal but I don't think it is the best way to go about the end goal because of the deployment trap. Email is a vast infrastructure and it is really hard to get any traction there because anything you do is diluted.
The application I am looking to apply this to is a condensation of an idea from the APWG which was for a 'constrained browser' without _javascript_ that would only be used for security sensitive applications like accessing bank web sites. So I took the idea further and reduced the browser to the absolute bare minimum which is to present the user with a HTML form which says:
"Sign the latest release [Yes][No]"
"Add T-Mobile as Bill Payment Recipient [Yes][No]"
"Do you want to transfer $10,000 to the Nigerian Prince [Yes][No]"
That is something that can be displayed on a phone or a watch.
This is one of the new applications the Mathematical Mesh supports.
The number of companies supporting the new application would be small but it would establish a constituency of validated brands and of users.
The constituency formed by the Mesh Confirmation Protocol could then be used to enable something interesting in the mail messaging space. But I think we are still looking at something that would be separate from the SMTP email infrastructure for high value communications such as those inside enterprises.
