Fwd: card_status - change-request to update allways

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: card_status - change-request to update allways

Myonium
Hi Werner

Any chance to get this change pushed into the next build?
----------------------snip-------------------------
diff --git a/g10/card-util.c b/g10/card-util.c
index 78cd52b..950b76f 100644
--- a/g10/card-util.c
+++ b/g10/card-util.c
@@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
   if (serialno && serialnobuflen)
     *serialno = 0;
 
-  rc = agent_scd_learn (&info, 0);
+  rc = agent_scd_learn (&info, 1);
   if (rc)
     {
       if (opt.with_colons)
----------------------snip————————————

Best,
Ben

Begin forwarded message:

From: Myonium <[hidden email]>
Subject: card_status - change-request to update allways
Date: May 14, 2017 at 11:29:32 GMT+2

Hi all

I would love to change the „card_status“ behavior to always update the "key stubs“. (It's only a 1 character change ;-)

Is there anything which would speak against making the following change:

diff --git a/g10/card-util.c b/g10/card-util.c
index 78cd52b..950b76f 100644
--- a/g10/card-util.c
+++ b/g10/card-util.c
@@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
 if (serialno && serialnobuflen)
   *serialno = 0;

-  rc = agent_scd_learn (&info, 0);
+  rc = agent_scd_learn (&info, 1);

With „force=true“ agent_scd_learn will always update the „key stub“. I.e. if a new card is attached containing the „private key“ of an already known keygrip it will update the stub so that the newly attached token can be used for crypto-operations.
I cannot think of any scenario where somebody does not want such a behavior or where this could brake anything. In case the user would shuffle back the old token the system would be reverted back to the old key stub.

Please advise. Many thanks,
Ben


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: card_status - change-request to update allways

NIIBE Yutaka
Myonium <[hidden email]> wrote:

> Any chance to get this change pushed into the next build?
> ----------------------snip-------------------------
> diff --git a/g10/card-util.c b/g10/card-util.c
> index 78cd52b..950b76f 100644
> --- a/g10/card-util.c
> +++ b/g10/card-util.c
> @@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
>    if (serialno && serialnobuflen)
>      *serialno = 0;
>  
> -  rc = agent_scd_learn (&info, 0);
> +  rc = agent_scd_learn (&info, 1);
>    if (rc)
>      {
>        if (opt.with_colons)
> ----------------------snip————————————

FYI, we have a ticket:

        https://dev.gnupg.org/T2898

under this parent ticket:

        https://dev.gnupg.org/T2291
--

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: card_status - change-request to update allways

Myonium
Thank you very much for notifying.
Yes that’s exactly what I’m trying to addressing.
Do you think this patch addresses the problem appropriate?
Is there anything I could help/contribute to get this implemented?

Thanks,
Ben  

 

> On Jun 5, 2017, at 09:46, NIIBE Yutaka <[hidden email]> wrote:
>
> Myonium <[hidden email]> wrote:
>> Any chance to get this change pushed into the next build?
>> ----------------------snip-------------------------
>> diff --git a/g10/card-util.c b/g10/card-util.c
>> index 78cd52b..950b76f 100644
>> --- a/g10/card-util.c
>> +++ b/g10/card-util.c
>> @@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
>>   if (serialno && serialnobuflen)
>>     *serialno = 0;
>>
>> -  rc = agent_scd_learn (&info, 0);
>> +  rc = agent_scd_learn (&info, 1);
>>   if (rc)
>>     {
>>       if (opt.with_colons)
>> ----------------------snip————————————
>
> FYI, we have a ticket:
>
> https://dev.gnupg.org/T2898
>
> under this parent ticket:
>
> https://dev.gnupg.org/T2291
> --


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Fwd: card_status - change-request to update allways

Myonium
In reply to this post by NIIBE Yutaka
Hi Niibe

Could you please advise how to get the change below pushed in the next release?
It is a very small change which makes the world for many of the smart card user much easier.

Thanks,
Ben

Begin forwarded message:

From: NIIBE Yutaka <[hidden email]>
Subject: Re: Fwd: card_status - change-request to update allways
Date: June 5, 2017 at 09:46:29 GMT+2

Myonium <[hidden email]> wrote:
Any chance to get this change pushed into the next build?
----------------------snip-------------------------
diff --git a/g10/card-util.c b/g10/card-util.c
index 78cd52b..950b76f 100644
--- a/g10/card-util.c
+++ b/g10/card-util.c
@@ -376,7 +376,7 @@ current_card_status (ctrl_t ctrl, estream_t fp,
  if (serialno && serialnobuflen)
    *serialno = 0;

-  rc = agent_scd_learn (&info, 0);
+  rc = agent_scd_learn (&info, 1);
  if (rc)
    {
      if (opt.with_colons)
----------------------snip————————————

FYI, we have a ticket:

https://dev.gnupg.org/T2898

under this parent ticket:

https://dev.gnupg.org/T2291
--


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: card_status - change-request to update allways

NIIBE Yutaka
Myonium <[hidden email]> wrote:
> Could you please advise how to get the change below pushed in the next release?

Sorry, it won't get in.  Yes, I understand your use case; You want to
replace private key stub in .gnupg/private-keys-v1.d.

For this use case, please remove your .gnupg/private-keys-v1.d/<KEYGRIP>.key
manually, and do "gpg --card-status".

The change you proposed has an impact to existing behavior, that is, it
always modifies the privat key file when 'gpg --card-status' is invoked.

Currently, GnuPG doesn't assume same key can be mutiple cards with
possiblly different serial number.
--

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: card_status - change-request to update allways

Myonium

> On Sep 20, 2017, at 07:25, NIIBE Yutaka <[hidden email]> wrote:
>
> Myonium <[hidden email]> wrote:
>> Could you please advise how to get the change below pushed in the next release?
>
> Sorry, it won't get in.  Yes, I understand your use case; You want to
> replace private key stub in .gnupg/private-keys-v1.d.
>
Yes correct. On "—card-status“ I want to update the stubs to whatever there is on the card … I want the use the keys on the attached smart card if possible.

> For this use case, please remove your .gnupg/private-keys-v1.d/<KEYGRIP>.key
> manually, and do "gpg --card-status“.
Yes that’s what I keep on doing all the time …
>
> The change you proposed has an impact to existing behavior, that is, it
> always modifies the privat key file when 'gpg --card-status' is invoked.
You are right. However that is exactly what I would expect on a „—card-status“. I cannot think of any situation where this could result in a unwanted conflict. Would you prefer modifying stubs only in case the card changed? Or are you questioning replacing a key stub at all. To my understanding stubs are -in case of smart cards- only pointers indicating where to find the private key ….
updating these pointers on a „—card-status“ seems to be a reasonable thing to me.
>
> Currently, GnuPG doesn't assume same key can be mutiple cards with
> possiblly different serial number.
This is definitely true for keys generated on the card. Fine for authentication keys. However when it comes to encryption this might not be a wise decision.
A card might brake and who wants to loose all encrypted documents if a card breaks? To my understanding encryption keys need "a offline backup“: I case a card beaks the encryption key can be pushed on the replacement card. If you use different form factors („Smart cards, Yubikey USB dongles, NFC enabled cards for mobiles) having the same keys on multiple cards makes totally sense ...

If you think „modifying stubs only in case the card changed“ would be an acceptable solution I would be volunteer to work on it  ...
_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: card_status - change-request to update allways

NIIBE Yutaka
Hello,

I think that I understand your case (partially, at least).  I don't deny
existence of such a use case.  And I admit it is a bit difficult to do
manual removal of private key file.

I think that it is because of the (historical) decision or assumption
serial number of card can be stable identifier.  I want to fix this,
too.

Myonium <[hidden email]> wrote:
> Would you prefer modifying stubs only in case the card changed?

Given the situation that GnuPG 2.2.x is bug fix only release(s), my idea
is avoiding small changes, but to introduce major change, real change
for card management, into master branch of GnuPG.

> To my understanding stubs are -in case of smart cards- only pointers
> indicating where to find the private key ….

Exactly.

It seems for me that we can remove this (non-)feature of recording
serial number in private key file, completely.

Currently, a serial number of the card is used as a kind of permanent
identifier of a card.  I think that we need to locate such assumptions
in the protocol and the implementation of gpg-agent and scdaemon.  Then,
we can fix them.

While T1983 was being fixed, gpg frontend introduced an access to
available card keys.  This is a step forward to use a serial number of
card as runtime/volatile identifier but not as permanent identifier.

I don't have whole picture at hand, not yet.  If possible, please help
us to locate the places in gpg-agent where it uses the recorded serial
number, and/or investigate how we can remove that.
--

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: card_status - change-request to update allways

Werner Koch
On Thu, 21 Sep 2017 11:55, [hidden email] said:

> It seems for me that we can remove this (non-)feature of recording
> serial number in private key file, completely.

One of the reasons to implemented the extended private key format was to
make it easier to add meta data to a private key.  For example several
S/N could be added to the private key file and it would also be easier
to automatically remove them.

Having a way to ask the user to insert a certain card using data which
is permanently associated with the card (printed serial number) is a
very useful feature and cannot, according to my experience, be replaced
by just asking for the key id or such.


Salam-Shalom,

   Werner


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: card_status - change-request to update allways

Myonium

> On Sep 21, 2017, at 14:23, Werner Koch <[hidden email]> wrote:
>
> On Thu, 21 Sep 2017 11:55, [hidden email] said:
>
>> It seems for me that we can remove this (non-)feature of recording
>> serial number in private key file, completely.
>
> One of the reasons to implemented the extended private key format was to
> make it easier to add meta data to a private key.  For example several
> S/N could be added to the private key file and it would also be easier
> to automatically remove them.
>
> Having a way to ask the user to insert a certain card using data which
> is permanently associated with the card (printed serial number) is a
> very useful feature and cannot, according to my experience, be replaced
> by just asking for the key id or such.

I think hinting the user which card to insert to for a card based key operation is a great feature I wouldn't like to miss.
There is a good chance that users will have multiple keys on different cards. If none of the attached cards contain a matching key this notice is very welcome.

In this respect the key stub as a memory entry where the private key was last seen, seems to be a good thing for me.
But it is frustrating if you get ask to insert a different card even so a card inserted contains a matching key.
Updating the stubs with „—card-status“ would work for me. An automatic check on all connected cards would be cool … but maybe slow ...

>
>
> Salam-Shalom,
>
>   Werner
>
>
> --
> Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: card_status - change-request to update allways

NIIBE Yutaka
In reply to this post by Werner Koch
Werner Koch <[hidden email]> wrote:
> Having a way to ask the user to insert a certain card using data which
> is permanently associated with the card (printed serial number) is a
> very useful feature and cannot, according to my experience, be replaced
> by just asking for the key id or such.

For some cards, it's true.  Card has a unique serial number by
manufacturer, which is printed on the card, and a user can recognize the
number.  A user _can_ use the unique serial number to identify his key.
Or... a user could have a practice to strongly assosicate his key to a
specific physical media with specific serial number.  I don't deny this
use case.

I know about, the use case of strong association between the serial
number and private keys; Some users want to do that.  (When he finds his
keys on different card, he might want to be notified.)  I don't propose
killing this.

My point is that the use of strong association should not be _required_
(or assumed) for all users always.

Speaking about my use case, I identify my tokens by its enclosure, like
blue one, red one, one with GPG logo, etc.  In this use case, it is more
useful for me to be notified "please insert red token" than "please
insert token with S/N: xxxx".  When I need, I check the serial number
by "gpg --card-status".

Please note that there are many tokens (Gnuk Token implementations,
Nitrokey, Yubikey, etc.), which are basically used without printed
serial number on the hardware.
--

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Reply | Threaded
Open this post in threaded view
|

Re: card_status - change-request to update allways

Werner Koch
On Mon, 25 Sep 2017 03:07, [hidden email] said:

> Speaking about my use case, I identify my tokens by its enclosure, like
> blue one, red one, one with GPG logo, etc.  In this use case, it is more

That would also benefit my uses cases.  I use one Zeitcontrol card
which I am used to identify by the serial number (also in
authorized_keys) but for the Gnuk a "insert your standard gnuk" would be
a better description for me.

What about this idea: We move the S/N out of the s-expression used to
describe the key into a name tag field in the extended private key
format file.  gnupg/agent/keyformat.txt has this description of the
exdended key format for quite some time:

  Description: Key to sign all GnuPG released tarballs.
    The key is actually stored on a smart card.
  Use-for-ssh: yes
  OpenSSH-cert: long base64 encoded string wrapped so that this
    key file can be easily edited with a standard editor.
  Key: (shadowed-private-key
    (rsa
    (n #00AA1AD2A55FD8C8FDE9E1941772D9CC903FA43B268CB1B5A1BAFDC900
    2961D8AEA153424DC851EF13B83AC64FBE365C59DC1BD3E83017C90D4365B4
    83E02859FC13DB5842A00E969480DB96CE6F7D1C03600392B8E08EF0C01FC7
    19F9F9086B25AD39B4F1C2A2DF3E2BE317110CFFF21D4A11455508FE407997
    601260816C8422297C0637BB291C3A079B9CB38A92CE9E551F80AA0EBF4F0E
    72C3F250461E4D31F23A7087857FC8438324A013634563D34EFDDCBF2EA80D
    F9662C9CCD4BEF2522D8BDFED24CEF78DC6B309317407EAC576D889F88ADA0
    8C4FFB480981FB68C5C6CA27503381D41018E6CDC52AAAE46B166BDC10637A
    E186A02BA2497FDC5D1221#)
    (e #00010001#)
    (shadowed t1-v1
     (#D2760001240102000005000011730000# OPENPGP.1)
    )))

All fields except for Key: are optional.  The "Description" field is
what it says and should be considered a plain comment on the key.  My
proposal now would be to write such a stub key with a new field

  Title: S/N 123456788990000

the first time a stub key is written or when it is updated.  The serial
number would be the default but the user could at any time change that
to whatever is more appropriate to be shown by Pinentry.  This would fix
the UI for key/card association.  

What to do for checking whether the right card is inserted is a
different question, though.  Maybe another field "Serial" which is used
for this unless "Title" is also set?



Salam-Shalom,

   Werner


--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: card_status - change-request to update allways

Werner Koch
In reply to this post by Myonium
On Thu, 21 Sep 2017 19:18, [hidden email] said:

> Updating the stubs with „—card-status“ would work for me. An automatic check on all connected cards would be cool … but maybe slow ...

Yes, that may delay other operations as well.  In particular when
scdaemon needs to test for several card applications.

Did someone mentioned that you can update the serial number in the key
stub using

  gpg-connect-agent 'learn --force' /bye

?


Salam-Shalom,

   Werner

--
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

_______________________________________________
Gnupg-devel mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

attachment0 (233 bytes) Download Attachment