From mofosyne at gmail.com Thu May 21 14:45:49 2015 From: mofosyne at gmail.com (mofo syne) Date: Thu, 21 May 2015 22:45:49 +1000 Subject: Proposal for uri for gnupg messages Message-ID: Is there a standard way to encode gpg keys or messages as a uri ? If not, here is a proposal for one. Typical application of this might be in transferring a cipertext from a screen to smartphone via a QR code, or from a poster (e.g. signed message on physical poster). e.g. For pubkey: gpg://pubkey;version:GnuPG+v2;$base64:: For pubkey (with implied encoding. Default for pubkey mode payload is base64): gpg://pubkey;version:GnuPG+v2;$:: For encrypted msg: gpg://msg;version:GnuPG+v2;$base64:: or a signed message gpg://sigmsg;hash:SHA1;sig:;$:: --------- # schema description What's the logic? This is actually inspired by the datauri scheme. e.g. this example from wikipedia data:[][;charset=][;base64], So the proposed scheme for this gnupg uri is: gpg:// [] [;key:value]<;$encoding_type::payload_data> The characters were chosen to not conflict with base64 accepted characters. Thus reducing parser complexity. We use the `gpg://` marker since `://` is used by many parser to detect urls and uri. `;` is used as a delimiter. The payload (implied keyname by mode) is defined as ` $encoding_type?length::payload ` where encoding_type defaults to the usual encoding for the current mode if left empty. You could have other encoding like none rfc1738 conforming octet stream like `octet?16::8bitbinarystream` hence the optional `?length` notation (could be omitted if it is always going to be transmitted in a fixed string array, e.g. QR code). Or a base64 encoded message like `$base64::` Also for `[;key:value]` there is an alternative form `[;key$encoding?length::value]` for specially encoded values (like octet signature or some future form of encoding). Very much similar to the form used for payload ## Mode keywords So far this is what I thought for gpg keywords for the `` * `pubkey` = public key * `prvkey` = private key * `encmsg` = encrypted message * `sigmsg` = signed message * `fprint` = key fingerprint --------- # Dealing with QR limited code size. A specific problem with QR codes is most phones cannot read the max density QR codes. Thus need to split the uri to multiple QR codes. (e.g. splitting a gpg public key in half) You have two approaches for encoding this. 1. Use structured append. This is more efficient, but requires more effort to generate each barcode, since it is a binary setting. But it is part of the QR standard. 2. Use nonstandard textual metadata "APPEND:" format e.g. `APPEND:1of3$PARITY?ID[;token][;key:value]::` (key:value or token field could define settings like compression `;lzma` or encoding `;base64`) . Pros: work on any QR generator. Cons: Not as space efficient as structured append. e.g. APPEND:1of3?clark.pub::gpg://mode:pubkey;version:GnuPG+v2;$base64:: APPEND:2of3?clark.pub::Some very long gpg message uri string here APPEND:3of3?clark.pub:: to be stitched together again and decoded ---------- # Other example Pubkey: gpg://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 fingerprint: gpg://fprint;comment:Arnold+Reinhold at world.std.com;$::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8