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::<base64 data>
For pubkey (with implied encoding. Default for pubkey mode payload is base64):
gpg://pubkey;version:GnuPG+v2;$::<base64 data>
For encrypted msg:
gpg://msg;version:GnuPG+v2;$base64::<base64 data>
or a signed message
gpg://sigmsg;hash:SHA1;sig:<base64>;$::<percent encoded message>
---------
# schema description
What's the logic? This is actually inspired by the datauri scheme.
e.g. this example from wikipedia
data:[<MIME-type>][;charset=<encoding>][;base64],<data>
So the proposed scheme for this gnupg uri is:
gpg:// [<mode>]
[;key:value]<;<explicit_key>$encoding_type<?length>::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::<base64 data>`
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 `<mode>`
* `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]::<your msg>` (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@world.std.com;$::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
_______________________________________________
Gpa-dev mailing list
Gpa-dev@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gpa-dev
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::<base64 data>
For pubkey (with implied encoding. Default for pubkey mode payload is base64):
gpg://pubkey;version:GnuPG+v2;$::<base64 data>
For encrypted msg:
gpg://msg;version:GnuPG+v2;$base64::<base64 data>
or a signed message
gpg://sigmsg;hash:SHA1;sig:<base64>;$::<percent encoded message>
---------
# schema description
What's the logic? This is actually inspired by the datauri scheme.
e.g. this example from wikipedia
data:[<MIME-type>][;charset=<encoding>][;base64],<data>
So the proposed scheme for this gnupg uri is:
gpg:// [<mode>]
[;key:value]<;<explicit_key>$encoding_type<?length>::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::<base64 data>`
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 `<mode>`
* `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]::<your msg>` (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@world.std.com;$::43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8
_______________________________________________
Gpa-dev mailing list
Gpa-dev@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gpa-dev
