Brand Indicators for Message Identification (BIMI) and VMC Implementation

ampliads · October 21, 2023, 5:26pm

Dear all,
Do anyone from our community have worked around with BIMI?
I tried to implement it for one of our client in healthcare industry (as they needed more secure and branded mail)
I have created and implemented BIMI without VMC certificate. (Because of Hight Costs Associated with VMC certificate)
The client have TradeMark Certificate but I am afraid that anyone would be interested to pay ~$1,000 - $1,500 bucks yearly for just showing their logo in mail.
Here is the way I have implemented BIMI Protocol using this article But it seems that Google and Apple will not display the logo without VMC.
Is their any way around for this?

Some Additional Info :
The domain I implemented BIMI

BIMI validator result

Thanks in Advance
Viral

danb35 · October 21, 2023, 6:47pm

This sounds like another iteration of the EV certificate, whose value has long been debunked. The funny thing is that it's the browser vendors--including Google and Apple--that have greatly devalued EV certs for websites (i.e., you don't get the company name in the address bar any more, the green background, or any of the indicators you used to get). And now it seems that the very same companies have come up with another idea that's essentially EV certs for email.

I'd say the chance that Let's Encrypt will provide VMC certs is the same as the chance that they'll provide EV certs--none. And for the same reason: LE depends on the ability to issue certs automatically, and certs of this sort cannot be issued automatically.

mcpherrinm · October 21, 2023, 7:44pm

Because of the manual verification required for VMC, Let’s Encrypt cannot implement it. I suspect there will never be a free or low cost option.

rg305 · October 21, 2023, 8:39pm

Those are two things.

Email security can be maintained using DANE/DNSSEC/DKIM/DMARC/SPF.
Why? are they being required?
IMHO, "email branding" is a waste of time - typical users will never see the EHLO/HELO names used nor rely on an image to discern the security level of an email; Nor will they refuse to open an email if it doesn't have a logo attached. [false sense of accomplishment].
I would "brand" the entire domain using DNSSEC [and stay away from such (expensive) email only "branding"].

No free/cheap way that I know off.

rg305 · October 21, 2023, 8:43pm

I imagine a "simple hack" that, once anyone has a working BIMI enabled domain, they can then change the image file to whatever they want.
All subsequent emails will show that new image.
Who validates the current image is directly related to the sending domain?
What a joke!

danb35 · October 21, 2023, 9:19pm

It kind of looks like the image itself is somehow referenced in the cert:

dan@Dan-MBP-2019  ~  step certificate inspect eharmony.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 17851193888661497321897982286182354595 (0xd6e03cf8649e1a7b8e83f497c820ea3)
    Signature Algorithm: SHA256-RSA
        Issuer: C=US,O=DigiCert, Inc.,CN=DigiCert Verified Mark RSA4096 SHA256 2021 CA1
        Validity
            Not Before: Nov 1 00:00:00 2021 UTC
            Not After : Nov 1 23:59:59 2022 UTC
        Subject: UnknownOID=2.5.4.15,UnknownOID=1.3.6.1.4.1.311.60.2.1.3,UnknownOID=1.3.6.1.4.1.311.60.2.1.2,SERIALNUMBER=4489504,C=US,ST=California,L=Los Angeles,STREET=Floor #17,STREET=10900 Wilshire Blvd,O=eHarmony, Inc.,CN=eHarmony, Inc.,UnknownOID=1.3.6.1.4.1.53087.1.3,UnknownOID=1.3.6.1.4.1.53087.1.4
        Subject Public Key Info:
            Public Key Algorithm: RSA
                Public-Key: (2048 bit)
                Modulus:
                    9c:c2:4e:3e:a9:5f:78:3f:64:2b:a9:e4:64:32:11:
                    99:5a:0b:0f:21:3d:c5:26:f9:f9:00:3a:6a:26:0a:
                    ce:0a:72:a8:d7:8d:3c:68:c8:68:a5:1f:93:69:e3:
                    af:e3:87:26:de:b9:63:8c:d7:ba:5f:e7:c3:23:ec:
                    0b:52:5c:7e:a3:ea:fd:48:c8:80:3c:37:aa:0b:39:
                    64:1f:ef:37:3b:cb:6a:6e:de:c7:c5:3f:1c:07:e0:
                    83:90:bc:ff:15:c8:4d:75:38:d6:2d:ac:02:77:5b:
                    c4:dd:1b:88:83:e1:ee:a1:e2:a0:4c:3d:7c:95:44:
                    03:a3:ce:d1:e7:f1:8e:0a:da:ef:1e:a8:21:9c:8f:
                    88:08:e7:57:86:36:62:fc:f8:ab:a9:08:58:4d:c9:
                    f8:a5:12:32:ab:b0:d7:26:6b:21:62:e6:7c:2b:16:
                    09:b7:36:49:3c:40:2c:da:3e:c7:41:d8:cf:b3:64:
                    b6:fd:12:8a:c2:1f:57:d1:9e:26:15:96:bc:f6:79:
                    3a:29:80:5e:db:8a:60:72:74:78:8b:21:5e:05:19:
                    08:a9:43:ff:2d:ee:de:f4:6f:ff:da:a1:d5:29:21:
                    41:c2:88:a4:d3:c8:40:5c:48:e3:22:2c:61:37:44:
                    26:b0:e0:25:fd:b9:12:c3:91:65:56:52:ca:64:e6:
                    53
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:BE:9F:BD:8D:57:6D:95:B5:AD:63:C3:97:4E:AB:A8:84:5D:3A:07:F5
            X509v3 Subject Key Identifier:
                77:94:0A:16:3F:5D:B2:F7:82:DF:56:3D:F1:A1:84:3D:07:61:4D:8B
            X509v3 Subject Alternative Name:
                DNS:eharmony.com
            X509v3 Extended Key Usage:
                1.3.6.1.5.5.7.3.31
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl3.digicert.com/DigiCertVerifiedMarkRSA4096SHA2562021CA1.crl, URI:http://crl4.digicert.com/DigiCertVerifiedMarkRSA4096SHA2562021CA1.crl
            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114412.0.2.5
                Policy: 1.3.6.1.4.1.53087.1.1
            Authority Information Access:
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertVerifiedMarkRSA4096SHA2562021CA1.crt
            X509v3 Basic Constraints: critical
                CA:FALSE
            1.3.6.1.5.5.7.1.12:
                0...........0...0...0.....image/svg+xml0#0!0...+..........^....E..8<[.....;.0.......data:image/svg+xml;base64,H4sIAAAAAAAACpWUXW+bMBSGr5Nf4Xk3qwTGHxibCFKl3egqbVKlSb2N0oQmaAQicL7263cwCSVbo2lCOvaxzfs+HGNHt4d1jnZpVWdlEWNGKEZpMS8XWbGM8da8uhrfjofRB9dFD2mRVjNTViM0WZQvKXrM821t7BDiPuGEOejH8wP6ctiUlUFP+XbpPhaI2MHn1mOEAkIputtm+QLRG4RcF+Tr3bIPwTF6mdXpU1W+ZnkaY5MVR3dTYwSwRR3jlTGbkeft93uyF6Sslh6nlHqgcloyOuRZ8fO9hSwMQ8/O4uFgl6X7u/IQY4oo4lQSyU6N1RnVm9kc7DdVWqfVLsXj4SAymcnTcfp1Vq3L4hh5bQ4TSwiDaDMzK5QtYjx9gt50yqcYwUfkMf5IJ5NkkmAEk98Z5URJx9dEqbnLAhLwU/QFkcGpH1DCtEPn1OmeXMCY0wT5rS/yC3vv+fMLAKmV5i2Az4kMHUbDRpBq18a8aZgNsqUSThOZ7ftOwyZdWCkciwaGg/tGSYKSJqFymkS1Seh0HlfgRB8uoTKR8lSdgJPQb96cWwhrzyyKbwsknQairc+8AeJdEF2wpLJhzNvPO5etU7/C5V9wJRN6Llq/4L2NeCshk/fMD4iACTgNgcNYSIQ6J723beX6A87VpIMs8+OyLHqcss8pE/X5XmO0KbPCwBlhYKqlo2AnOLJ6QaOn/0gUJ4G6XAWFQYPBVdeg78pC8O259uW67UfnvyI82TEREva3XVOUqErnpuemrBscUcYYiGB0jLFWRMEJhZunqF/Lah3j9cxU2eETJYoqhtxTe9m4QsP+wAlnXEJlNL/pvmKSCCUnGO2zhVnF2P7RGK3SbLky5/QKnz7zaUb8Fo8xRbT//3yBJlwJ4GOCCLim3vi4AL7kn3yDyINLKGruwfHwN7xjetTaBQAA
            RFC6962 Certificate Transparency SCT:
                SCT [0]:
                    Version: V1 (0x0)
                    LogID: VVlTrjCWAIBs0utSCKbJnpMYKKwQVrRCHFU2FUxfdaw=
                    Timestamp: Nov 1 18:18:05.206 2021 UTC
                    Signature Algorithm: SHA256-ECDSA
                      30:44:02:20:22:57:89:9b:65:3c:31:60:7d:86:f7:07:4f:df:
                      44:61:7a:c2:5c:04:65:f7:06:31:d0:a2:36:3b:a6:b4:25:15:
                      02:20:3d:68:d9:40:4b:11:dd:20:4e:f1:bd:94:a4:81:da:2c:
                      fb:ba:04:22:dd:b2:be:79:f3:7a:fe:28:b1:e0:45:0c
    Signature Algorithm: SHA256-RSA
         10:cf:a1:0b:33:85:04:32:ae:b3:d8:5d:82:76:10:b0:64:8f:
         ba:46:f4:d8:64:c6:cc:93:38:24:e6:ab:cf:cd:0b:9c:5e:cf:
         b4:6d:ab:f4:62:96:0c:ce:08:15:82:70:2f:9b:f0:d8:3e:b5:
         44:d5:6c:84:03:62:c6:af:c0:45:05:5a:9f:d5:be:ad:27:48:
         4c:72:40:fa:47:41:90:8d:b8:a5:67:c4:6a:92:46:59:8f:24:
         ef:f7:9f:65:fd:49:17:07:a0:48:d5:f2:4a:54:a9:16:bb:d8:
         0f:0c:8d:c8:cf:a3:68:b9:a4:ad:7d:d6:62:2a:fb:6e:1d:f0:
         9d:8d:64:f7:05:fe:a8:53:09:0f:84:16:c4:ca:60:c2:a8:12:
         c6:5f:0b:b0:61:0a:4a:12:e4:1d:bb:35:71:4e:82:2d:80:c3:
         4f:82:4c:cc:19:57:df:ef:43:c4:21:72:35:81:32:53:ad:76:
         3f:fc:c6:c5:a0:bf:0a:55:f1:40:02:ca:93:04:a5:5d:11:15:
         39:0e:7a:ed:bb:9b:bf:db:4d:6b:ce:dd:bc:69:e4:11:6a:77:
         78:96:79:88:50:b8:9b:92:1e:f7:73:f4:8e:59:db:49:1f:be:
         d9:db:b6:84:e7:de:62:e2:d5:5c:b5:69:a3:34:54:eb:62:da:
         6a:65:66:c0:b1:30:11:3f:90:93:d2:9b:79:97:d1:a1:c7:bc:
         03:a3:6f:19:c7:fb:63:04:1b:41:87:77:76:ec:5c:85:da:91:
         94:98:35:73:b3:3a:4a:44:c3:1b:33:f1:f3:cf:c1:70:28:64:
         1e:ca:3f:f5:01:33:a6:c4:ef:92:ab:e6:66:96:ef:2d:98:70:
         98:e6:c2:77:66:46:86:b5:18:93:c0:b2:b1:bb:db:69:ab:a6:
         63:c5:ad:63:50:ff:56:f5:14:b8:f2:e5:2b:a4:41:97:39:d6:
         84:e3:c9:4b:da:43:84:65:21:6c:6f:f9:98:d5:87:6a:66:cc:
         0b:e0:96:e0:47:a3:16:0b:b3:dc:d0:7d:8b:31:92:f6:2d:e0:
         46:44:27:d6:51:aa:c5:39:91:20:af:ea:89:01:38:8a:0b:96:
         05:f9:3c:f1:47:05:97:a6:87:95:94:01:d3:42:f6:30:fa:2e:
         24:4a:06:83:4e:ad:34:d4:69:93:99:f4:88:db:0e:67:fb:8e:
         1a:ff:e7:1a:fc:bd:dc:ba:45:6a:48:64:6f:c5:de:8e:a2:18:
         b8:45:c6:ec:9a:8f:29:a1:ec:08:ac:ae:25:b1:65:58:3e:bd:
         0f:19:e2:45:62:0a:42:99:e6:d1:0a:25:08:03:4c:36:c7:6d:
         2b:96:af:1b:35:9b:5d:be
 dan@Dan-MBP-2019  ~ 

It's interesting, though, that that cert has been expired almost a year.

Google didn't find much for me about the technical specs of a VMC cert, but one of Digicert's pages listed eHarmony as one business that uses them. dig txt default._bimi.eharmony.com got the URL for the cert, curl downloaded it (a chain of three certs, actually), and the SmallStep CLI utility produced the output above. But again, the NotAfter date on that cert is 1 Nov 22--apparently eHarmony didn't see ongoing value in this kind of cert, but still kept the DNS records in place.

rg305 · October 21, 2023, 9:26pm

OK, so... the image is manually validated by the CA?

danb35 · October 21, 2023, 9:30pm

Why not? Again, it looks like EV certs warmed over. But I admit I'm only guessing at the purpose of the 1.3.6.1.5.5.7.1.12 field in this cert.

rg305 · October 21, 2023, 9:32pm

Hacking Hacker Noon: Cross-Site Scripting attacks via crafted SVG images | by Ax Sharma | AxDB | Medium

Aside from that, the XML can be a link to a picture contained some other file.
So, the cert doesn't have to change to change the picture - LOL

danb35 · October 21, 2023, 9:40pm

It does, because the logo itself is embedded in the cert. The contents of the 1.3.6.1.5.5.7.1.12 field include a base64-encoded, gzip'd .svg file. The contents of that file are:

<?xml version="1.0" encoding="utf-8"?>
<!-- Generator: Adobe Illustrator 24.2.1, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
<svg version="1.2" baseProfile="tiny-ps" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
	viewBox="0 0 205.51 205.51" xml:space="preserve">
	<title>eHarmony</title>
	<g>
		<path id="_Path__2_" fill="#0AAFAF" d="M102.75,48.77c-16.62-16.62-43.56-16.62-60.18,0c0,0,0,0,0,0l30.1,30.15L102.75,48.77z"/>
		<path id="_Path_2_2_" fill="#058782" d="M42.59,109l30.08-30.08l-30.1-30.15c-16.63,16.61-16.64,43.55-0.03,60.18
			C42.55,108.97,42.57,108.99,42.59,109z"/>
		<path id="_Path_3_2_" fill="#F05F55" d="M162.94,109c16.63-16.61,16.64-43.55,0.03-60.18c-0.02-0.02-0.03-0.03-0.05-0.05
			l-30.08,30.15L162.94,109z"/>
		<path id="_Path_4_2_" fill="#FFA082" d="M102.75,48.77l30.1,30.15l30.08-30.15C146.31,32.16,119.37,32.16,102.75,48.77
			C102.75,48.77,102.75,48.77,102.75,48.77z"/>
		<polygon id="_Path_5_2_" fill="#5F7DC8" points="132.85,78.92 102.76,48.82 102.76,48.82 72.67,78.92 102.76,109 		"/>
		<polygon id="_Path_6_2_" fill="#195F78" points="72.67,78.92 42.59,109 42.57,109 72.67,139.1 102.76,109 		"/>

			<rect id="_Path_7_2_" x="111.57" y="87.71" transform="matrix(0.7071 -0.7071 0.7071 0.7071 -38.1551 125.8582)" fill="#AF375A" width="42.55" height="42.55"/>

			<rect id="_Path_8_2_" x="81.47" y="117.84" transform="matrix(0.7071 -0.7071 0.7071 0.7071 -68.2731 113.3999)" fill="#23375F" width="42.55" height="42.55"/>
	</g>
</svg>

...and when rendered as an image, you get this:

...all in the cert itself. But that makes me wonder why the BIMI standard wants you to include a URL for the logo, when the cert already includes that logo.

It remains unclear to me what prevents other CAs from issuing these certs--it appears that only two CAs do--or what convoluted openssl invocation would be required to make one.

rg305 · October 21, 2023, 10:05pm

I still stand on:

Why use XML at all?
Why insist on an SVG file?
Why insist on GZIP?

Each of which leaves room for error/exploit.
That's too much risk for me - I rather like to sleep at night, I'm out!

danb35 · October 21, 2023, 10:40pm

No doubt I'm speaking out of turn, because I don't have any direct knowledge on any of these things. But as what I think are reasonable guesses:

Because that's inherent to SVG--see the next answer.

(1) because it's scalable without loss of quality; (2) because it's small in size, limiting the size of the cert or file that needs to be sent; and (3) the fewer options there are in a standard, the simpler it is.

I don't know that it's insisted on--I haven't seen any sort of RFC or other standard document mandating it. But assuming it's required, points (2) and (3) above would apply here as well.

If we assume there's any value in this at all (which I doubt, but that's a separate discussion), an email client has to be able to present a logo image at a size that's recognizable to users. This likely includes scaling up for users who have large print set on their devices. And it needs to be included with every certificate that's issued, and that cert and logo need to be sent to every person who receives an email, and they have to come from the company's own servers, rather than a SMTP provider who sends out the ~~spam~~ bulk email. That .svg, gzip'd, is 715 bytes. A .jpg or .png would be at least an order of magnitude larger.

So, if we accept the value of doing something like this in the first place (which I don't, really), limiting the logo to a gzip'd .svg kind of makes sense.

rg305 · October 21, 2023, 10:51pm

It is a sad day when the industry can't produce something that is secure AND reasonably sized.
[like all days that end with "y"]

This BIMI thing is definitely something with "good intentions".
But it looks [to me] like something that can all too easily be misused/exploited.
Even the desired outcome isn't really that impressive in the end anyway [to me].

ampliads · October 22, 2023, 4:40pm

That was the exact thought I got while I worked around with the exhaustive list of implementation. Moreover, BIMI DON'T CARE TO SERVE THE LOGO IMAGE FROM THE BRAND SITE'S DOMAIN. (www.mybrand.com/logo-tiny_ts.svg)

ampliads · October 22, 2023, 4:45pm

Thank @rg305 for these insights. It feels more practical to invest in DANE/DNSSEC/DKIM/DMARC/SPF I wish to give a try to DNSSEC.
Kind request to know your opinion on below setup:
Origin Server Secured By Let's Encrypt Cert
DNS By Cloudflare with DNSSEC (Traffic between cl and origin server will be encrypted by self signed cert , in our case, by let's encrypt)

Ty in Advance

ampliads · October 22, 2023, 5:10pm

Final updates from my side
At least, I have successfully validated tiny_ps.svg and did work around but It finally seems that its all things are MEANINGLESS without VMC, moreover, @rg305 is valid, its better to invest in other security measures than this BIMI thing.

My final (and may be last) work update on BIMI stuff:
Domain Configured with valid SVG :
https://www.ornawell.com

Tool used to validate:
https://bimivalidator.authmilter.org/

Results

May be, I will focus more on other security measures.

system · November 21, 2023, 5:10pm

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.