[openpgp] Re: Using OpenPGP card hardware security devices w ith modern key packets
Heiko Schäfer <[email protected]> Wed, 29 Jul 2026 21:01:55 +0000
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============4722817042837315178==
Content-Type: multipart/alternative;
boundary="------------YT8bzd94obMmsYlW9tXYupYk"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------YT8bzd94obMmsYlW9tXYupYk
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 7/29/26 7:00 PM, Simon Josefsson wrote:
>> Your proposed scheme for example is entirely hostile to casual human
>> inspection of the hint field on the card, and also resists local key
>> lookup using a fingerprint substring straight from the card.
> Neither humans nor software should be mapping (parts of) the fingerprint
> to OpenPGP card "hint" field, should they? So if that is harder, it may
> be considered a feature.
I think there are legitimate reasons for users to want to inspect the
"fingerprint" values on a card.
For example, if a user has two physically identical-looking OpenPGP card
devices, and they want to figure out which is which.
In some cases they may want to dump the card's metadata with a low-level
tool, and reason about the output manually.
As Paul wrote, this is certainly not the most important consideration.
But it's a nice property to have, if we can have it cheaply enough.
And (repeating myself) I don't think uniqueness of the "hint" field is
an important concern here (also see my mail from half an hour ago).
If we absolutely want to have more entropy in the field, then I think
"20 byte fingerprint prefix" (as suggested e.g. by Simo) is the natural
choice.
--------------YT8bzd94obMmsYlW9tXYupYk
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 7/29/26 7:00 PM, Simon Josefsson
wrote:<br>
</div>
<blockquote type="cite" cite="mid:[email protected]">
<pre class="moz-quote-pre" wrap=""><blockquote type="cite"
style="color: #007cff;"><pre wrap="" class="moz-quote-pre">Your proposed scheme for example is entirely hostile to casual human
inspection of the hint field on the card, and also resists local key
lookup using a fingerprint substring straight from the card.
</pre></blockquote><pre wrap="" class="moz-quote-pre">Neither humans nor software should be mapping (parts of) the fingerprint
to OpenPGP card "hint" field, should they? So if that is harder, it may
be considered a feature.</pre></pre>
</blockquote>
<br>
I think there are legitimate reasons for users to want to inspect
the "fingerprint" values on a card.<br>
<br>
For example, if a user has two physically identical-looking OpenPGP
card devices, and they want to figure out which is which.<br>
In some cases they may want to dump the card's metadata with a
low-level tool, and reason about the output manually.<br>
<br>
As Paul wrote, this is certainly not the most important
consideration.<br>
But it's a nice property to have, if we can have it cheaply enough.<br>
<br>
<br>
And (repeating myself) I don't think uniqueness of the "hint" field
is an important concern here (also see my mail from half an hour
ago).<br>
If we absolutely want to have more entropy in the field, then I
think "20 byte fingerprint prefix" (as suggested e.g. by Simo) is
the natural choice.
</body>
</html>
--------------YT8bzd94obMmsYlW9tXYupYk--
--===============4722817042837315178==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK
--===============4722817042837315178==--