You might see a few copies around. This one is edited and streamlined with
some advice from Hasimir to help keep this proposal focused.
Last updated: 2015-05-23 - edit: Switched from `openpgp://` to `openpgp:`
as noted by hobarrera. Also sent to openpgp(_at_)ietf(_dot_)org for further
discussion.
This is only a concept of specifically "alternative to openpgp blocks as
uri" at the moment, so exact implementation is still up in the air. The
main aim is to spur discussion.
*=============================*
*OPENPGP URI PROPOSAL (DRAFT)*
*=============================*
*## Brief/Objective ####################*
This proposal is to provide an alternative to the openpgp block messages,
in the form of a uri ( e.g. `http://` ). This would make such messages more
web friendly, as well as taking advantage of autolaunching apps to handle
such messages. Such links may be embedded within email messages or
webclients, or as a 2d barcode on a physical poster.
This aims to be flexible and futureproof, by supporting any mix of
variables or payload that may be thrown in it's way (e.g. percent
encoding, base64, etc... )
This will hopefully make accessing and using openpgp as convenient as
datauri (transmitting data), and mailto (launches email handlers easily).
*## Schema Description ##*
openpgp: [<mode>] [;key:value] [;key<?length><!encoding>::value]
<;<?length><!encoding>::payload_data>
* `openpgp:` - is the start of the openpgp uri ( This is the scheme
name that calls for a handler)
* `;` - is used as a delimiter.
* `[;key:value]` - for simple keyvalues: `;name:clark`
* `[;key<?length><!encoding>::value]`
- `::` - is used to aid visual inspection, since the
content would be more of a long complex string, rather than a simple
key:value pair
- `[;key?length:value]` - safely read in string: `;name?10::clark;kent`
- `[;key?encoding:value]` - `;sig!base64::f4h5k34589ht...`
* `<;<?length><!encoding>::payload_data>`
- payload do not require key value. But it has optional encoding and
length (Which may have a default setting based on mode. E.g. public keys
are often always encoded in base64 )
- `;::f4h5k34589ht...`
- `;!base64::f4h5k34589ht...`
- `;!octet?100::8BinaryStream`
- `;!json?17::{"key":[1,2,3,4]}`
* `$encoding` - is used to define how the string is encoded, e.g.
base64,json,1010101
* `?length` - is used to define how many characters to read ahead as a
string. Afterwards, it will just keep scanning for the next `;` or end of
string.
* `#type` this might be needed if we need to declare the type of a variable
(undecided if it is needed in this standard proposal)
*### Mode keywords ###*
So far this is what I thought for gpg keywords for the `<mode>`
* `pubkey` = public key
* `prvkey` = private key
* `encmsg` = encrypted message
* `sigmsg` = signed message
* `fprint` = key fingerprint
*### extra thoughts ###*
* http://tools.ietf.org/html/rfc1738 - Uniform Resource Locators (URL)
* http://tools.ietf.org/html/rfc3986 - Uniform Resource Identifier (URI):
Generic Syntax
* http://tools.ietf.org/html/rfc3987 - Internationalized Resource
Identifiers (IRIs)
*# Structure Examples #############*
e.g.
For pubkey:
openpgp:pubkey;version:GnuPG+v2;!base64::<base64 data>
For pubkey (with implied encoding. Default for pubkey mode payload is
base64):
openpgp:pubkey;version:GnuPG+v2;::<base64 data>
For encrypted msg:
openpgp:msg;version:GnuPG+v2;!base64::<base64 data>
or a signed message
openpgp:sigmsg;hash:SHA1;sig:<base64>;!::<percent encoded message>
*# Potential Usage ###############*
* Storing messages in QR or NFC allows for secure verifiable posters.
- This could allow people to trust messages stuck on posters on the
streets. E.g. safety information from organizations
- Paper letters could contain important messages/keys that can be then
decrypted/collected via a smartphone.
* Easier handling of messages in webrowsers via webrowsers plugins that can
recognise the uri handler calls.
- E.g. Clicking on a url will automatically open up a openpgp program that
automatically processes the message.
* IRC? Could have real time signing of messages with inlines opengpg uri
(with the appropriate plugins)
* Can do anything that a normal openpgp block can do (But with the main
advantage of being url safe, unless intentionally in octet mode etc...)
- So can override the need for keyserver uris,
# Considerations ###############
* Even if we do eventually come to a standard. What can we do to encourage
web browser coders to whitelist `opengpg:` scheme name, and thus allow
external programs or plugins to handle the uri. This is since some browsers
use a whitelist (I think firefox uses a whitelist, since preferences only
shows certain schemes).
*# Uri Mockups ################*
Pubkey:
openpgp:pubkey;version:GnuPG+v2;!base64::mQENBFVS5CYBCACmDH67cDfC+0ow2FVX4uzsiOfA1OA4ZSJVwVjBQeotgr3a5CWCWSbW+kw3CjlRQXcL4bxTNisGAfrtn78+GkEmS48mb9kAPi084flEBHmgHbzo0TI3az74S3UI3ZkLxuAdfD4G7BuVn7YPzOa3OgD3FW1zZ3EGsHSl3+i0QZZ0fPvi4OkC+w4vDjrkUGR/afy7AzQhYzMA22kf3PTvZMxS0RLJvoRbnyoGjd1aQZPJD4mMziBaySRKEdhAbIrogu2nW0M2aJmwiW1Sgp8PP8bH2PJPgXFKaRTucm3k2IdsxVx0u29VJiSq4ktrYm8cJ3ABfUWbd/4adUFMbqwY2UhBABEBAAG0M0p1c3R3YW50dG9oYXZlZnVuNTYgPGp1c3R3YW50dG9oYXZlZnVuNTZAd2FzdGUuY29tPokBOQQTAQgAIwUCVVLkJgIbAwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEGNU/RWXfXCybfQH/jZLLuWdeqOj/bNFx6OHxNLc8hYKbuje+xtZNP4gagCJboiAxPoWDfrhVQLKfKwR2mslAqQWdLSL1w93C/L1ByzXUz5sXA2YOTGVLXMU0aKQxYg3hBPqyc66F26Rz8mVLnOHGQoGvlVA4CMFNwEpS3lMkxbNyoQLeS1wXJsZN8VmDa5vqzQySCmOuBJ0rDqbwLrYNshPVqdo1G7U0uoTjPTI65+GlKvtXLxqn/R7c/aywqE9qinK/L0uyiQ4itA0er6TwI8d8B1Fw8JvbDmJNx24zHqOjZWL1Osn5o7ZH31AmFH7VFFJWtcYkpgTf2KETZ/PvkPPV/RL0q9FiKcB7725AQ0EVVLkJgEIAMl4rKSFfLXrB3MlwmNZqp66/5ixBm8FN1o3Hj9/xhiHWWZWwmkL3pfWVGI4GvFpOyh26VTv6Hvt54rvaqGYPZsz2jRO8PmVQs8g3CmC21F20jqi1fNu8m50ntrvK6qOK0pC7l7XXXkLwF9ChwxE8ott3WKALMS6+Z8RD0h/2SoNfW80dMLyDr2MzZdEB+dX6FM3YajkVaaIrhesedOsPoJOpPJc/K0BF71YjecesUUJZFdGm5v5UkgPbptuXgRFQWbQcj0kpQT4oxjwUImLYWb86cSJn6Bw7aHD9h/7ZHF5Q/N8s5fsl6lAEPEI2hTTh0SJE5g8qqL5YRfX7QBy1d0AEQEAAYkBHwQYAQgACQUCVVLkJgIbDAAKCRBjVP0Vl31wsnapB/9D0IBTxRNfWz3jsUbcfnI5Vu4V7mBu9B6rO6NfgpMirf2XaPmC13nQjR3WFZqd6JeJ1GPupkhleau1oViVHvKB7rfKOUqt0MNecWuHNu7tGp2q+k0NTEnA8/F5BGj3yxKdWNZ1farQDVnz39Pcj17XZK7R6FXLcQRf/yMjkipp6AAzADMTulsu86JAo4TLix83SsSXEzdID8p0REVRZZCTI8VHxlGjKOJBUu2K6IL5P80NMbEfHqXpxroftQhsuMQPGhlMgzDlWe7Mt+H5i/v3Sa4dKEQ0fW3kX/abF0xo4zDvbsRgoMgC8Z4QBfW29SAWMlSEqgl+yP6S59CPWwJ1=VzYv
encmsg:
openpgp:encmsg;!base64::hQIMA2gg7mYL/9/3ARAAnICjOZZ2BPY/ly2y8kMN7wvnKKrWiIF8y4is5Az6+irsFc4XlAJ8ieKAQsxE9E8nopRoZySe9L6bPDQPr8dq1kYPN9eFaNkW+E1z0B1iV4c3LrT1iGLsDrNJEODB8zytkYayc75RkuuA3iRkZj5Qco1fiv3DVNlnYRyPkXVQBwVVUPXaSowWHCMCPMS+ZmiNiqNd4ZiN3Dah7mB87mK5ed8rZM03RBtS4QPpR9t3Ku4y1W58FuAeFqf3CrLpDrf/4U3+98RiI1Z3/zsqjblXZ0/uuNDQnFZvgpOZ1q6Ry1Z3N03U94vgvs3XjrIm6raQajBXrvGsQIbgbSEkBldzNA0r0afcTPeaHTaOMcHqGA68b7Ju9yvYVk0BSyVbrW/oK93wT4SAxgq8wCPKlocp+KZx6qofSf7v/SdIKwMRgm2r2X0lTQTggElVG3sc00YcqS2a1kizmLPeyTOjai1Nt3vhySGFO48+SGUXbeMdtMtJEmjk9SFquVHEUkcd1/0X89OWnVn+vDuhtKMvAWhLFGC+m9pXCA6YJxWZwPTtTmFSOdsnYFEEU5J/jpl7Rmtev3AaBsZKRwgQlP24vz4zBzfMatTxLu7KBLeneyRPvzMe16dolYJtBSSFj7R0iXEy5GhKGLuckGWPL9mCzgGT8NSJZVPsrCoAYCo75hEnSEzSTQGJlgriakR505zTMr4YtSDZnNZh9XFwZ2Wy64PwO5DexBgytHIEFQrqULfGoWUMYlIJAzDmkDx7eWcDwyWo5tZ8Uiv0pGJC6iM6krgs=/Kcn
fingerprint:
openpgp:fprint;version:OpenPGPv3;name:clark+kent;::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
openpgp:fprint;::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
Some potential future json (Not easy to transmit however, due to non uri
standard characters in json ):
openpgp:testmode;key!json?17::{"key":[1,2,3,4]}
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp