From gniibe at fsij.org  Tue Jan  5 04:03:16 2021
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 05 Jan 2021 12:03:16 +0900
Subject: How to enable ack button functionality on FST-01sz
In-Reply-To: <1042827516.3547959.1609362820915@mail.yahoo.com>
References: <1042827516.3547959.1609362820915.ref@mail.yahoo.com>
 <1042827516.3547959.1609362820915@mail.yahoo.com>
Message-ID: <87h7nwdr0r.fsf@iwagami.gniibe.org>

Mark Debian wrote:
> Can someone tell me how to enable the ack button functionality using
> FST-01sz?  When I configure latest gnuk, before compiling, the output
> of the configure command says:"Acknowledge button is supported"

Currently, it is only supported in GnuPG in master (to be 2.3).
With "--card-edit" option, we have "uif" sub-command (User Interaction
Flag) to enable/disable the functionality.  When enabled, a user
has to acknowledge the operation (sign/decrypt/auth) by the device.

Personally, I don't use it.  For SSH key, I use the feature of gpg-agent
which asks confirmation (by pop-up window on desktop).
-- 


From mark_debian at yahoo.com  Wed Jan  6 16:19:51 2021
From: mark_debian at yahoo.com (Mark Debian)
Date: Wed, 6 Jan 2021 15:19:51 +0000 (UTC)
Subject: How to enable ack button functionality on FST-01sz
In-Reply-To: <87h7nwdr0r.fsf@iwagami.gniibe.org>
References: <1042827516.3547959.1609362820915.ref@mail.yahoo.com>
 <1042827516.3547959.1609362820915@mail.yahoo.com>
 <87h7nwdr0r.fsf@iwagami.gniibe.org>
Message-ID: <967691809.4756495.1609946391891@mail.yahoo.com>

 > > Can someone tell me how to enable the ack button functionality using
> > FST-01sz?? When I configure latest gnuk, before compiling, the output
> > of the configure command says:"Acknowledge button is supported"

> Currently, it is only supported in GnuPG in master (to be 2.3).
> With "--card-edit" option, we have "uif" sub-command (User Interaction
> Flag) to enable/disable the functionality.? When enabled, a user
> has to acknowledge the operation (sign/decrypt/auth) by the device.
Ahhh.? I see.? Even debian sid still only has version?2.2.20

> Personally, I don't use it.? For SSH key, I use the feature of gpg-agent
> which asks confirmation (by pop-up window on desktop).
I hadn't been worried about this use until recently.
Correct me if I am wrong:
After you insert and use your Gnuk token smartcard the gpg-agent will cache your password.? If someone has backdoor shell access then they can simply use your key until you remove it from the USB port.? You would not even notice that your key is being used.
I think you can configure the gpg-agent to ask the password every time but that is a bit of a pain if you have a decent password length.? In any case, someone with backdoor shell access could just reconfigure the agent to cache the password again without you knowing or even keylog your password.
If you force the ack button functionality on the Gnuk then this can't be disabled by an attacker without your master passphrase.? You could ensure that you only enabled the ack button functionality, and only entered the master passphrase, using an air-gapped trusted machine.? If you followed this use case then you would never need to enter the master passphrase for normal use and therefore it would never be entered on your normal work machine.? The ack button functionality will then require you to use a magnet to acknowledge the key use every time.? An attacker with remote access _and your passphrase_ would still not be able to "press" the ack button nor disable its requirement.
Otherwise how do you counter the threat of someone gaining backdoor shell access to your account?? That is the threat that the smartcard ultimately provides the extra protection against.
Regards,Mark.

    On Tuesday, 5 January 2021, 01:03:25 pm AEST, NIIBE Yutaka <gniibe at fsij.org> wrote:  
 
 Mark Debian wrote:
> Can someone tell me how to enable the ack button functionality using
> FST-01sz?? When I configure latest gnuk, before compiling, the output
> of the configure command says:"Acknowledge button is supported"

Currently, it is only supported in GnuPG in master (to be 2.3).
With "--card-edit" option, we have "uif" sub-command (User Interaction
Flag) to enable/disable the functionality.? When enabled, a user
has to acknowledge the operation (sign/decrypt/auth) by the device.

Personally, I don't use it.? For SSH key, I use the feature of gpg-agent
which asks confirmation (by pop-up window on desktop).
-- 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20210106/b6a6d030/attachment.html>

From mark_debian at yahoo.com  Wed Jan  6 16:13:04 2021
From: mark_debian at yahoo.com (Mark Debian)
Date: Wed, 6 Jan 2021 15:13:04 +0000 (UTC)
Subject: How to enable ack button functionality on FST-01sz
In-Reply-To: <87h7nwdr0r.fsf@iwagami.gniibe.org>
References: <1042827516.3547959.1609362820915.ref@mail.yahoo.com>
 <1042827516.3547959.1609362820915@mail.yahoo.com>
 <87h7nwdr0r.fsf@iwagami.gniibe.org>
Message-ID: <326342051.4757024.1609945984903@mail.yahoo.com>

 On Tuesday, 5 January 2021, 01:03:25 pm AEST, NIIBE Yutaka <gniibe at fsij.org> wrote:
 
 
 > Mark Debian wrote:
> > Can someone tell me how to enable the ack button functionality using
> > FST-01sz?? When I configure latest gnuk, before compiling, the output
> > of the configure command says:"Acknowledge button is supported"

> Currently, it is only supported in GnuPG in master (to be 2.3).
> With "--card-edit" option, we have "uif" sub-command (User Interaction
> Flag) to enable/disable the functionality.? When enabled, a user
> has to acknowledge the operation (sign/decrypt/auth) by the device.
Ahhh.? I see.? Even debian sid still only has version?2.2.20

> Personally, I don't use it.? For SSH key, I use the feature of gpg-agent
> which asks confirmation (by pop-up window on desktop).
I hadn't been worried about this use until recently.
Correct me if I am wrong:
After you insert and use your Gnuk token smartcard the gpg-agent will cache your password.? If someone has backdoor shell access then they can simply use your key until you remove it from the USB port.? You would not even notice that your key is being used.
I think you can configure the gpg-agent to ask the password every time but that is a bit of a pain if you have a decent password length.? In any case, someone with backdoor shell access could just reconfigure the agent to cache the password again without you knowing or even keylog your password.
If you force the ack button functionality on the Gnuk then this can't be disabled by an attacker without your master passphrase.? You could ensure that you only enabled the ack button functionality, and only entered the master passphrase, using an air-gapped trusted machine.? If you followed this use case then you would never need to enter the master passphrase for normal use and therefore it would never be entered on your normal work machine.? The ack button functionality will then require you to use a magnet to acknowledge the key use every time.? An attacker with remote access _and your passphrase_ would still not be able to "press" the ack button nor disable its requirement.
Otherwise how do you counter the threat of someone gaining backdoor shell access to your account?? That is the threat that the smartcard ultimately provides the extra protection against.
Regards,Mark.
-- 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20210106/30f5faad/attachment.html>

From wk at gnupg.org  Wed Jan  6 19:44:18 2021
From: wk at gnupg.org (Werner Koch)
Date: Wed, 06 Jan 2021 19:44:18 +0100
Subject: How to enable ack button functionality on FST-01sz
In-Reply-To: <967691809.4756495.1609946391891@mail.yahoo.com> (Mark Debian via
 Gnuk-users's message of "Wed, 6 Jan 2021 15:19:51 +0000 (UTC)")
References: <1042827516.3547959.1609362820915.ref@mail.yahoo.com>
 <1042827516.3547959.1609362820915@mail.yahoo.com>
 <87h7nwdr0r.fsf@iwagami.gniibe.org>
 <967691809.4756495.1609946391891@mail.yahoo.com>
Message-ID: <87czyhlxbx.fsf@wheatstone.g10code.de>

On Wed,  6 Jan 2021 15:19, Mark Debian said:

> After you insert and use your Gnuk token smartcard the gpg-agent will
> cache your password.? If someone has backdoor shell access then they

No.  The agent does not cacge the PIN or passphrase - this is done by
the smartcard.

> Otherwise how do you counter the threat of someone gaining backdoor
> shell access to your account?? That is the threat that the smartcard
> ultimately provides the extra protection against.

You can't.  The smartcard protects your key but it can't really protect
the use of the key as long as the smartcard is plugged in.

BTW, Forcing a user to enter the Admin-PIN is pretty easy.  Just let the
malware use up the the PIN along with some social engineering and most
users will enter the Admin PIN to unblock the PIN...


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20210106/24a53aad/attachment.sig>

From mark_debian at yahoo.com  Wed Jan  6 22:31:18 2021
From: mark_debian at yahoo.com (Mark Debian)
Date: Wed, 6 Jan 2021 21:31:18 +0000 (UTC)
Subject: How to enable ack button functionality on FST-01sz
In-Reply-To: <87czyhlxbx.fsf@wheatstone.g10code.de>
References: <1042827516.3547959.1609362820915.ref@mail.yahoo.com>
 <1042827516.3547959.1609362820915@mail.yahoo.com>
 <87h7nwdr0r.fsf@iwagami.gniibe.org>
 <967691809.4756495.1609946391891@mail.yahoo.com>
 <87czyhlxbx.fsf@wheatstone.g10code.de>
Message-ID: <1721726340.4853761.1609968678839@mail.yahoo.com>

 Werner Koch said:
> > After you insert and use your Gnuk token smartcard the gpg-agent will> > cache your password.? If someone has backdoor shell access then they

> No.? The agent does not cacge the PIN or passphrase - this is done by> the smartcard.

OK.? I see.

> > Otherwise how do you counter the threat of someone gaining backdoor> > shell access to your account?? That is the threat that the smartcard> > ultimately provides the extra protection against.

> You can't.? The smartcard protects your key but it can't really protect> the use of the key as long as the smartcard is plugged in.

I don't like that.

> BTW, Forcing a user to enter the Admin-PIN is pretty easy.? Just let the> malware use up the the PIN along with some social engineering and most> users will enter the Admin PIN to unblock the PIN...

However education can protect against that threat.? Only ever use the Admin-PIN in the trusted air-gapped machine.? Furthermore, if you get your PIN wrong when you know you typed it correctly then that can be a warning that there is some malware on your PC.? If you have users of the smartcard that are not very knowledgeable then you can set things up for them so that only you have the Admin-PIN and they need to come to you to unblock the PIN if there is a problem.

Otherwise, how do you guard against the malware / backdoor threat on your PC?? Wouldn't the malware just wait for you to plug in the smartcard and enter your passphrase and then proceed to use your key before you can pull out the smartcard?? For example, if you use your gpg key for authenticating ssh access then the malware could immediately set up that shell access too.
Thanks for explaining / detailing the treat model better.

Do you think that one of the crypto hardware wallets is a better device to protect against this threat?? For example, the Trezor-T has a PIN pad built into the device so you always enter the PIN on the hardware device.

However, when I looked at the Trezor-T it can only generate the gpg key on the device itself and seems directly dependent on the original seed phrase.? This means that the gpg key can be recovered on a new device if the original seed phrase is entered.? But, this also means that you can't have a master key with subkeys type of setup where only the subkeys are on the hardware device.? There seems to be no way to transfer a gpg subkey to the Trezor-T device.

Maybe it would be possible to enable gnupg use through scanning of QR codes somehow???? Some of the crypto hardware wallets are doing the signing of crypto transactions using QR codes and the device itself remains always air-gapped - it is never actually plugged into a PC.? See for example Ngrave.??
NGRAVE | Unrivaled crypto security and seamless experience


| 
| 
| 
|  |  |

 |

 |
| 
|  | 
NGRAVE | Unrivaled crypto security and seamless experience

The first end-to-end solution for managing your crypto. The Coldest hardware Wallet. The Coldest key back-up. No...
 |

 |

 |


BTW: I do not have one of these devices and have no association with the company.

Regards,Mark.

    On Thursday, 7 January 2021, 04:45:11 am AEST, Werner Koch <wk at gnupg.org> wrote:  
 
 On Wed,? 6 Jan 2021 15:19, Mark Debian said:

> After you insert and use your Gnuk token smartcard the gpg-agent will
> cache your password.? If someone has backdoor shell access then they

No.? The agent does not cacge the PIN or passphrase - this is done by
the smartcard.

> Otherwise how do you counter the threat of someone gaining backdoor
> shell access to your account?? That is the threat that the smartcard
> ultimately provides the extra protection against.

You can't.? The smartcard protects your key but it can't really protect
the use of the key as long as the smartcard is plugged in.

BTW, Forcing a user to enter the Admin-PIN is pretty easy.? Just let the
malware use up the the PIN along with some social engineering and most
users will enter the Admin PIN to unblock the PIN...


Salam-Shalom,

? Werner

-- 
Die Gedanken sind frei.? Ausnahmen regelt ein Bundesgesetz.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20210106/a894985c/attachment.html>

From wk at gnupg.org  Thu Jan  7 10:49:36 2021
From: wk at gnupg.org (Werner Koch)
Date: Thu, 07 Jan 2021 10:49:36 +0100
Subject: How to enable ack button functionality on FST-01sz
In-Reply-To: <1721726340.4853761.1609968678839@mail.yahoo.com> (Mark Debian
 via Gnuk-users's message of "Wed, 6 Jan 2021 21:31:18 +0000 (UTC)")
References: <1042827516.3547959.1609362820915.ref@mail.yahoo.com>
 <1042827516.3547959.1609362820915@mail.yahoo.com>
 <87h7nwdr0r.fsf@iwagami.gniibe.org>
 <967691809.4756495.1609946391891@mail.yahoo.com>
 <87czyhlxbx.fsf@wheatstone.g10code.de>
 <1721726340.4853761.1609968678839@mail.yahoo.com>
Message-ID: <878s95krf3.fsf@wheatstone.g10code.de>

On Wed,  6 Jan 2021 21:31, Mark Debian said:

>> BTW, Forcing a user to enter the Admin-PIN is pretty easy.? Just let
>> the> malware use up the the PIN along with some social engineering
>> and most> users will enter the Admin PIN to unblock the PIN...
>
> However education can protect against that threat.? Only ever use the

Yes with proper SecOPs training you could do that but that also involves
a lot of other procedures, hardware and people.  The reality is
different.

Even with a touch-to-sign button you still don't known what you actually
sign or whether the displayed PDF is the PDF actually sent out.  A
compromised box is a game-over condition.  Tilt.  Restart from scratch.
You _may_ not need to re-boot your public key infrastructure due to the
token, though.


Shalom-Salam,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20210107/dce78bbf/attachment.sig>

From mark_debian at yahoo.com  Thu Jan  7 11:47:58 2021
From: mark_debian at yahoo.com (Mark Debian)
Date: Thu, 7 Jan 2021 10:47:58 +0000 (UTC)
Subject: How to enable ack button functionality on FST-01sz
In-Reply-To: <878s95krf3.fsf@wheatstone.g10code.de>
References: <1042827516.3547959.1609362820915.ref@mail.yahoo.com>
 <1042827516.3547959.1609362820915@mail.yahoo.com>
 <87h7nwdr0r.fsf@iwagami.gniibe.org>
 <967691809.4756495.1609946391891@mail.yahoo.com>
 <87czyhlxbx.fsf@wheatstone.g10code.de>
 <1721726340.4853761.1609968678839@mail.yahoo.com>
 <878s95krf3.fsf@wheatstone.g10code.de>
Message-ID: <1613852448.4952881.1610016478294@mail.yahoo.com>

 
> Even with a touch-to-sign button you still don't known what you actually> sign or whether the displayed PDF is the PDF actually sent out.? A

Hmm.? I guess not.

> compromised box is a game-over condition.? Tilt.? Restart from scratch.
> You _may_ not need to re-boot your public key infrastructure due to the
> token, though.
Yes.
It sounds like you really need a smartcard with a built in touch screen for entering the PIN and also displaying confirmation about just what you are signing.
Is there any device like the NGrave device for use with GnuPG which is air gapped and achieves the cryptographic signatures through scanning QR codes or the like?
Regards,Mark.

    On Thursday, 7 January 2021, 07:50:12 pm AEST, Werner Koch <wk at gnupg.org> wrote:  
 
 On Wed,? 6 Jan 2021 21:31, Mark Debian said:

>> BTW, Forcing a user to enter the Admin-PIN is pretty easy.? Just let
>> the> malware use up the the PIN along with some social engineering
>> and most> users will enter the Admin PIN to unblock the PIN...
>
> However education can protect against that threat.? Only ever use the

Yes with proper SecOPs training you could do that but that also involves
a lot of other procedures, hardware and people.? The reality is
different.

Even with a touch-to-sign button you still don't known what you actually
sign or whether the displayed PDF is the PDF actually sent out.? A
compromised box is a game-over condition.? Tilt.? Restart from scratch.
You _may_ not need to re-boot your public key infrastructure due to the
token, though.


Shalom-Salam,

? Werner


-- 
Die Gedanken sind frei.? Ausnahmen regelt ein Bundesgesetz.  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20210107/2d280b8e/attachment.html>

From szczepan at nitrokey.com  Tue Jan 26 14:32:33 2021
From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey)
Date: Tue, 26 Jan 2021 14:32:33 +0100
Subject: Enable KDF-DO on a populated GNUK
In-Reply-To: <d832af15-7a49-e888-1842-707d8376299c@nitrokey.com>
References: <d832af15-7a49-e888-1842-707d8376299c@nitrokey.com>
Message-ID: <0bd2ced3-8283-a008-05d3-db00d8e7f749@nitrokey.com>

Hello,

>From my tests it turned out that currently with the recent GNUK 1.2.15
and GnuPG 2.2.25 it is not possible to set up a KDF-DO on a populated /
personalized device (with keys). As a user I would like to have such
option, so I would not be forced through factory reset.

On requesting KDF setting in such case GNUK replies with:
```
2021-01-26 12:35:05 scdaemon[22] DBG:  response: sw=6F00  datalen=0
2021-01-26 12:35:05 scdaemon[22] failed to set 'KDF': Card error
```

Is having this GnuPG [1] patch sufficient to make that work, or are
there any changes needed in the GNUK itself?

Best regards,
Szczepan


[1] https://dev.gnupg.org/T3891

-- 
Szczepan Zalega
Senior Software Developer

Nitrokey GmbH
https://www.nitrokey.com

Email: szczepan at nitrokey.com
Nickname: szszszsz

Rheinstr. 10 C, 14513 Teltow, Germany
CEO / Gesch?ftsf?hrer: Jan Suhr
Register: AG Potsdam, HRB 32882 P
VAT ID / USt-IdNr.: DE300136599


From gniibe at fsij.org  Thu Jan 28 03:56:39 2021
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 28 Jan 2021 11:56:39 +0900
Subject: Enable KDF-DO on a populated GNUK
In-Reply-To: <0bd2ced3-8283-a008-05d3-db00d8e7f749@nitrokey.com>
References: <d832af15-7a49-e888-1842-707d8376299c@nitrokey.com>
 <0bd2ced3-8283-a008-05d3-db00d8e7f749@nitrokey.com>
Message-ID: <87k0rx93bs.fsf@iwagami.gniibe.org>

Hello,

KDF-DO should be used, that is common practice for using Gnuk.

Szczepan Zalega  wrote:
> From my tests it turned out that currently with the recent GNUK 1.2.15
> and GnuPG 2.2.25 it is not possible to set up a KDF-DO on a populated /
> personalized device (with keys). As a user I would like to have such
> option, so I would not be forced through factory reset.

No, it's not possible for Gnuk.  Originally, when it was proposed, it
was designed/implemented that KDF-DO setup should be done with no key
materials.  And Gnuk keeps this constraint.

Well, I'm afraid that convenience here introduces complexity of
implementation and confusion about how KDF-DO should be used.

Given the situation that it is not currently supported, if it will be
supported by someone else in future, a user has to do flash new firmware
losing keys on card, anyway, so, I don't think adding this new option
makes any sense.

Rather, for me, it makes sense to go opposite direction, instead; ... to
refuse keytocard/key-generation when KDF-DO is not available.

> Is having this GnuPG [1] patch sufficient to make that work, or are
> there any changes needed in the GNUK itself?

No, the patch is supporting other implementations of OpenPGPcard.
-- 


From azarubkin at gmail.com  Thu Jan 28 10:02:27 2021
From: azarubkin at gmail.com (Alexandr Zarubkin)
Date: Thu, 28 Jan 2021 12:02:27 +0300
Subject: Logging to Windows with Gnuk
Message-ID: <CAPuotoY_7SJDGb=SB6a7ak6LuzmXvGNs=7p+9KA_QcG5rHNfSQ@mail.gmail.com>

Hi everyone,

I've managed to log into Windows using a certificate stored on Gnuk. I had
to add MSE command support and raise the reported OpenPGP version to 3.3.
It's just a proof of concept, but it works. The changes are located at
https://github.com/me21/gnuk and https://salsa.debian.org/me21/gnuk,
platformio branch.
The tests were performed on the virtual machine running Windows 7.

Kind regards,
Alexander Zarubkin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20210128/17f9cb8e/attachment.html>

From szczepan at nitrokey.com  Thu Jan 28 10:56:08 2021
From: szczepan at nitrokey.com (Szczepan Zalega | Nitrokey)
Date: Thu, 28 Jan 2021 10:56:08 +0100
Subject: Enable KDF-DO on a populated GNUK
In-Reply-To: <87k0rx93bs.fsf@iwagami.gniibe.org>
References: <d832af15-7a49-e888-1842-707d8376299c@nitrokey.com>
 <0bd2ced3-8283-a008-05d3-db00d8e7f749@nitrokey.com>
 <87k0rx93bs.fsf@iwagami.gniibe.org>
Message-ID: <3cb18523-09f7-82e0-08f9-c60ba16cb953@nitrokey.com>

On 1/28/21 3:56 AM, NIIBE Yutaka wrote:
> KDF-DO should be used, that is common practice for using Gnuk.
> 
> Szczepan Zalega  wrote:
>> From my tests it turned out that currently with the recent GNUK 1.2.15
>> and GnuPG 2.2.25 it is not possible to set up a KDF-DO on a populated /
>> personalized device (with keys). As a user I would like to have such
>> option, so I would not be forced through factory reset.
> 
> No, it's not possible for Gnuk.  Originally, when it was proposed, it
> was designed/implemented that KDF-DO setup should be done with no key
> materials.  And Gnuk keeps this constraint.
> 
> (...)
> Rather, for me, it makes sense to go opposite direction, instead; ... to
> refuse keytocard/key-generation when KDF-DO is not available.
> 

I see. That sounds like a good idea. We have left normal PIN use
available due to a compatibility reasons (with longer length required),
but perhaps indeed it should be faded out in the future in favor of KDF-DO.
Thank you for the clarification!

Best regards,
Szczepan


-- 
Szczepan Zalega
Senior Software Developer

Nitrokey GmbH
https://www.nitrokey.com

Email: szczepan at nitrokey.com
Nickname: szszszsz

Rheinstr. 10 C, 14513 Teltow, Germany
CEO / Gesch?ftsf?hrer: Jan Suhr
Register: AG Potsdam, HRB 32882 P
VAT ID / USt-IdNr.: DE300136599


From simon at josefsson.org  Thu Jan 28 10:10:47 2021
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 28 Jan 2021 10:10:47 +0100
Subject: Enable KDF-DO on a populated GNUK
In-Reply-To: <87k0rx93bs.fsf@iwagami.gniibe.org> (NIIBE Yutaka's message of
 "Thu, 28 Jan 2021 11:56:39 +0900")
References: <d832af15-7a49-e888-1842-707d8376299c@nitrokey.com>
 <0bd2ced3-8283-a008-05d3-db00d8e7f749@nitrokey.com>
 <87k0rx93bs.fsf@iwagami.gniibe.org>
Message-ID: <87r1m5l948.fsf@latte.josefsson.org>

NIIBE Yutaka <gniibe at fsij.org> writes:

> Rather, for me, it makes sense to go opposite direction, instead; ... to
> refuse keytocard/key-generation when KDF-DO is not available.

Yes please!  I have forgotten this sometimes, and it is annoying.
Having it fail early seems more reliable.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20210128/126527bc/attachment.sig>