RFC 6350 has a “Security Properties” section which only has a “KEY” field. Public keys tend to be huge; likely too big for a Vcard that will then be encoded as a QR code that needs to fit on a business card. Also too big for a Vcard that would be SMS-transmitted. And it does not take much to throw LaTeX’s QR code package out of bounds:

ERROR: TeX capacity exceeded, sorry [main memory size=5000000]

It would be far more sensible in most cases to include a fingerprint of a public key, which is just a reasonably short hash of the key. But strangely, RFC 6350 seems to only define a field for whole keys. I thought surely I must be missing something. But indeed it’s an oversight. Someone else noticed the problem as well:

https://www.av8n.com/computer/htm/distributing-keys.htm

A fingerprint can probably be stuffed ad hoc into the NOTES field. But without structure it’s not so easy for the person importing the Vcard.

John Denker proposes a reasonable hack for PGP users. But is there nothing for OMEMO fingerprints that an app like #Snikket can make easy use of?

Update

Apparently there is a URI standard format for specifying an OMEMO fingerprint which resembles something like this:

xmpp:[email protected]?omemo-sid-123456789=A1B2C3D4E5F6G7H8I9…

So although there is no vcard integration, there is at least a way to do a separate QR code.

I have 3 fingerprints (one for each XMPP device) and it would not be ideal to have 3 separate QR codes. This vague bug report seems to suggest multiple fingerprints can be concatinated in a single record.. or is the author requesting that?

The command xmppc -m omemo generates URIs, but it produces a separate record for each fingerprint.