[Opensc-devel] Repeated login issues with Yubikey NEO

[David Woodhouse]

I'm using a Yubikey NEO with OpenSC, from the OpenConnect VPN client.

It starts off by doing a test signature to validate that I've given it a
matching certificate and key, which works fine. PKCS#11 Spy output at
http://forum.yubico.com/viewtopic.php?f=26&t=1586

Then it connects to the HTTPS server and is required to do client
certificate authentication, so it tries another signature. Which fails
thus:


22: C_SignInit
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x2a3b950
Returned: 0 CKR_OK

23: C_Sign
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
[in] pData[ulDataLen] 00007fff6dbbf6b0 / 36
00000000 42 B1 2E A0 4B A2 D6 C0 AD C0 CA 28 AD 0F 5D 34 B...K......(..]4
00000010 09 AD 6C 8C 2C A1 31 1E 13 FF 91 65 59 A3 9D D9 ..l.,.1....eY...
00000020 24 89 88 9D $...
[out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
Returned: 0 CKR_OK

24: C_Sign
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
[in] pData[ulDataLen] 00007fff6dbbf6b0 / 36
00000000 42 B1 2E A0 4B A2 D6 C0 AD C0 CA 28 AD 0F 5D 34 B...K......(..]4
00000010 09 AD 6C 8C 2C A1 31 1E 13 FF 91 65 59 A3 9D D9 ..l.,.1....eY...
00000020 24 89 88 9D $...
Returned: 257 CKR_USER_NOT_LOGGED_IN

I believe that's a violation of the PKCS#11 spec because
CKR_USER_NOT_LOGGED_IN isn't a valid return value from C_Sign(). You're
supposed to return that from C_SignInit() if it's the case.

We modified GnuTLS to attempt to re-login when a key had the
CKA_ALWAYS_AUTHENTICATE attribute set:
https://gitorious.org/gnutls/gnutls/commit/e1a0af191

The GnuTLS pkcs11_login() function, however, does this first:

25: C_GetSessionInfo
2014-11-06 19:56:41.534
[in] hSession = 0xed7620
[out] pInfo:
slotID: 1
state: ' CKS_RO_USER_FUNCTIONS'
flags: 4
CKF_SERIAL_SESSION
ulDeviceError: 0
Returned: 0 CKR_OK

It sees the CKS_RO_USER_FUNCTIONS and decides that it didn't need to log
in again after all. And then the C_Sign still fails.

So I hacked it not to do that, and to call C_Login unconditionally. Now
I get this...

28: C_Login
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] userType = CKU_USER
[in] pPin[ulPinLen] 000000000293d9c0 / 6
00000000 31 32 33 34 35 36 123456

Returned: 256 CKR_USER_ALREADY_LOGGED_IN
p11: Login result = 256

29: C_SignInit
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x269da90
Returned: 0 CKR_OK

30: C_Sign
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] pData[ulDataLen] 00007fff4449d3d0 / 36
00000000 E9 44 15 2E 2F 04 6F 66 78 9B F1 9F 35 20 1D
EB .D../.ofx...5 ..
00000010 A7 8B A1 B9 70 99 36 1B 9E 75 73 2D 4D 8F 7A
A6 ....p.6..us-M.z.
00000020 7D DE 54 B7 }.T.

[out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
Returned: 0 CKR_OK

31: C_Sign
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] pData[ulDataLen] 00007fff4449d3d0 / 36
00000000 E9 44 15 2E 2F 04 6F 66 78 9B F1 9F 35 20 1D
EB .D../.ofx...5 ..
00000010 A7 8B A1 B9 70 99 36 1B 9E 75 73 2D 4D 8F 7A
A6 ....p.6..us-M.z.
00000020 7D DE 54 B7 }.T.

Returned: 257 CKR_USER_NOT_LOGGED_IN


Full log including OPENSC_DEBUG=9 output at
http://david.woodhou.se/opensc-debug.txt — that final failing C_Sign()
call looks like this (not the same run, so don't be surprised that the
data we're signing are different):

0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] reader-pcsc.c:249:pcsc_transmit: reader 'Yubico Yubikey NEO OTP+CCID 00 00'
0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
Outgoing APDU data [ 260 bytes] =====================================
10 87 07 9C FF 7C 82 01 06 82 00 81 82 01 00 00 .....|..........
01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF 00 84 0A 81 DA 22 ..............."
F5 48 AA 5F 12 18 9C 93 DF 99 D2 B5 A4 BA 7F 20 .H._...........
81 09 FF 51 ...Q
======================================================================
0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] reader-pcsc.c:182:pcsc_internal_transmit: called
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
Incoming APDU data [ 2 bytes] =====================================
90 00 ..
======================================================================
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:526:sc_transmit: called
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:380:sc_single_transmit: called
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:385:sc_single_transmit: CLA:0, INS:87, P1:7, P2:9C, data(11) 0x7fffe321f54f
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] reader-pcsc.c:249:pcsc_transmit: reader 'Yubico Yubikey NEO OTP+CCID 00 00'
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
Outgoing APDU data [ 17 bytes] =====================================
00 87 07 9C 0B 9F C1 10 C1 2F 5D 66 C2 E1 54 28 ........./]f..T(
00 .
======================================================================
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] reader-pcsc.c:182:pcsc_internal_transmit: called
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:185:sc_apdu_log:
Incoming APDU data [ 2 bytes] =====================================
69 82 i.
======================================================================
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card.c:361:sc_unlock: called
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card-piv.c:493:piv_general_io: DEE r=0 apdu.resplen=0 sw1=69 sw2=82
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] iso7816.c:102:iso7816_check_sw: Security status not satisfied
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card-piv.c:503:piv_general_io: Card returned error


Is this simply a card error, and/or is it something that OpenSC should
be able to deal with?

[Nikos Mavrogiannopoulos]

Post by David Woodhouse
I'm using a Yubikey NEO with OpenSC, from the OpenConnect VPN client.
It starts off by doing a test signature to validate that I've given it a
matching certificate and key, which works fine. PKCS#11 Spy output at
http://forum.yubico.com/viewtopic.php?f=26&t=1586
Then it connects to the HTTPS server and is required to do client
certificate authentication, so it tries another signature. Which fails
30: C_Sign
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] pData[ulDataLen] 00007fff4449d3d0 / 36
[...]
[out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
Returned: 0 CKR_OK
31: C_Sign
2014-11-06 20:02:11.599
[...]
Returned: 257 CKR_USER_NOT_LOGGED_IN

To clarify why the two calls to C_Sign are there. The first call gets
the signature length (so sets data to NULL), and the second signs the
data. The bug seems to be on some authentication check which sets the
smart card to require login after the first call to C_Sign. My guess
would be that this check is on the firmware of the card, but someone who
knows opensc better may be able to help more.

regards,
Nikos



------------------------------------------------------------------------------

[David Woodhouse]

Post by Nikos Mavrogiannopoulos
To clarify why the two calls to C_Sign are there. The first call gets
the signature length (so sets data to NULL), and the second signs the
data. The bug seems to be on some authentication check which sets the
smart card to require login after the first call to C_Sign. My guess
would be that this check is on the firmware of the card, but someone
who knows opensc better may be able to help more.

Looking at the PCSC_DEBUG output, I don't think it even talks to the
hardware at all during the (later) C_GetSessionInfo, C_Login, C_SignInit
and first C_Sign calls. It's only when it actually wants to the do the
signature that it talks to the card... and gets an unhelpful response.

[Douglas E Engert]

Post by David Woodhouse
I'm using a Yubikey NEO with OpenSC, from the OpenConnect VPN client.
It starts off by doing a test signature to validate that I've given it a
matching certificate and key, which works fine. PKCS#11 Spy output at
http://forum.yubico.com/viewtopic.php?f=26&t=1586
Then it connects to the HTTPS server and is required to do client
certificate authentication, so it tries another signature. Which fails
22: C_SignInit
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x2a3b950
Returned: 0 CKR_OK
23: C_Sign
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
[in] pData[ulDataLen] 00007fff6dbbf6b0 / 36
00000000 42 B1 2E A0 4B A2 D6 C0 AD C0 CA 28 AD 0F 5D 34 B...K......(..]4
00000010 09 AD 6C 8C 2C A1 31 1E 13 FF 91 65 59 A3 9D D9 ..l.,.1....eY...
00000020 24 89 88 9D $...
[out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
Returned: 0 CKR_OK
24: C_Sign
2014-11-06 16:32:39.499
[in] hSession = 0x28a1560
[in] pData[ulDataLen] 00007fff6dbbf6b0 / 36
00000000 42 B1 2E A0 4B A2 D6 C0 AD C0 CA 28 AD 0F 5D 34 B...K......(..]4
00000010 09 AD 6C 8C 2C A1 31 1E 13 FF 91 65 59 A3 9D D9 ..l.,.1....eY...
00000020 24 89 88 9D $...
Returned: 257 CKR_USER_NOT_LOGGED_IN

THe code is using the PIV driver as defined in NIST 800-73-3. It has 4 cert/key on the card:
The auth cert is used for authentication to web sites and logins,
The encrypt cert/key is for encryption,
the card auth cert is so the card can authenticate itself, and does not require the PIN.

The sign cert/key is used to sign e-mail and such,
for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
as defined in NIST 800-73-3.

The card enforces the the CKA_ALWAYS_AUTHENTICATE on the sign cert/key by
no allowing any intervening operations to the card between the presentation
of the PIN,and the crypto operation.

Post by David Woodhouse
I believe that's a violation of the PKCS#11 spec because
CKR_USER_NOT_LOGGED_IN isn't a valid return value from C_Sign(). You're
supposed to return that from C_SignInit() if it's the case.

Well, That is the closest return we can give you that the card did not allow the sign
operation.

Post by David Woodhouse
We modified GnuTLS to attempt to re-login when a key had the
https://gitorious.org/gnutls/gnutls/commit/e1a0af191
25: C_GetSessionInfo
2014-11-06 19:56:41.534
[in] hSession = 0xed7620
slotID: 1
state: ' CKS_RO_USER_FUNCTIONS'
flags: 4
CKF_SERIAL_SESSION
ulDeviceError: 0
Returned: 0 CKR_OK
It sees the CKS_RO_USER_FUNCTIONS and decides that it didn't need to log
in again after all. And then the C_Sign still fails.
So I hacked it not to do that, and to call C_Login unconditionally. Now
I get this...
28: C_Login
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] userType = CKU_USER
[in] pPin[ulPinLen] 000000000293d9c0 / 6
00000000 31 32 33 34 35 36 123456
Returned: 256 CKR_USER_ALREADY_LOGGED_IN

Yes it failed, so the C_SignInit and C_Sign go on to try to use the signing cert
with the CKA_ALWAYS_AUTHENTICATE without sending the pin again.


Incoming APDU data [ 2 bytes] =====================================
69 82 i.
======================================================================
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card.c:361:sc_unlock: called
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card-piv.c:493:piv_general_io: DEE r=0 apdu.resplen=0 sw1=69 sw2=82
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] iso7816.c:102:iso7816_check_sw: Security status not satisfied
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card-piv.c:503:piv_general_io: Card returned error
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card.c:361:sc_unlock: called
0x7f6d5bc2a840 20:44:36.443 [opensc-pkcs11] card-piv.c:553:piv_general_io: returning with: -1211 (Security status not satisfied)

So the problem it to get that second C_Login to work.

userType = CKU_USER
should be
userType = CKU_CONTEXT_SPECIFIC

PKCS#11 2.20 section 10.9

Re-authentication occurs by calling C_Login with userType set to
CKU_CONTEXT_SPECIFIC immediately after a cryptographic operation using the
key has been initiated (e.g. after C_SignInit). In this call, the actual user type is
implicitly given by the usage requirements of the active key. If C_Login returns
CKR_OK the user was successfully authenticated and this sets the active key in an
authenticated state that lasts until the cryptographic operation has successfully or
unsuccessfully been completed (e.g. by C_Sign, C_SignFinal,..).

Post by David Woodhouse
p11: Login result = 256
29: C_SignInit
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x269da90
Returned: 0 CKR_OK
30: C_Sign
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] pData[ulDataLen] 00007fff4449d3d0 / 36
00000000 E9 44 15 2E 2F 04 6F 66 78 9B F1 9F 35 20 1D
EB .D../.ofx...5 ..
00000010 A7 8B A1 B9 70 99 36 1B 9E 75 73 2D 4D 8F 7A
A6 ....p.6..us-M.z.
00000020 7D DE 54 B7 }.T.
[out] pSignature[*pulSignatureLen] NULL [size : 0x100 (256)]
Returned: 0 CKR_OK
31: C_Sign
2014-11-06 20:02:11.599
[in] hSession = 0x2c089a0
[in] pData[ulDataLen] 00007fff4449d3d0 / 36
00000000 E9 44 15 2E 2F 04 6F 66 78 9B F1 9F 35 20 1D
EB .D../.ofx...5 ..
00000010 A7 8B A1 B9 70 99 36 1B 9E 75 73 2D 4D 8F 7A
A6 ....p.6..us-M.z.
00000020 7D DE 54 B7 }.T.
Returned: 257 CKR_USER_NOT_LOGGED_IN
Full log including OPENSC_DEBUG=9 output at
http://david.woodhou.se/opensc-debug.txt — that final failing C_Sign()
call looks like this (not the same run, so don't be surprised that the
0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] reader-pcsc.c:249:pcsc_transmit: reader 'Yubico Yubikey NEO OTP+CCID 00 00'
Outgoing APDU data [ 260 bytes] =====================================
10 87 07 9C FF 7C 82 01 06 82 00 81 82 01 00 00 .....|..........
01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ................
FF FF FF FF FF FF FF FF FF FF 00 84 0A 81 DA 22 ..............."
F5 48 AA 5F 12 18 9C 93 DF 99 D2 B5 A4 BA 7F 20 .H._...........
81 09 FF 51 ...Q
======================================================================
0x7f6d5bc2a840 20:44:36.827 [opensc-pkcs11] reader-pcsc.c:182:pcsc_internal_transmit: called
Incoming APDU data [ 2 bytes] =====================================
90 00 ..
======================================================================
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:526:sc_transmit: called
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:380:sc_single_transmit: called
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] apdu.c:385:sc_single_transmit: CLA:0, INS:87, P1:7, P2:9C, data(11) 0x7fffe321f54f
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] reader-pcsc.c:249:pcsc_transmit: reader 'Yubico Yubikey NEO OTP+CCID 00 00'
Outgoing APDU data [ 17 bytes] =====================================
00 87 07 9C 0B 9F C1 10 C1 2F 5D 66 C2 E1 54 28 ........./]f..T(
00 .
======================================================================
0x7f6d5bc2a840 20:44:36.857 [opensc-pkcs11] reader-pcsc.c:182:pcsc_internal_transmit: called
Incoming APDU data [ 2 bytes] =====================================
69 82 i.
======================================================================
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:395:sc_single_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] apdu.c:548:sc_transmit: returning with: 0 (Success)
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card.c:361:sc_unlock: called
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card-piv.c:493:piv_general_io: DEE r=0 apdu.resplen=0 sw1=69 sw2=82
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] iso7816.c:102:iso7816_check_sw: Security status not satisfied
0x7f6d5bc2a840 20:44:36.869 [opensc-pkcs11] card-piv.c:503:piv_general_io: Card returned error
Is this simply a card error, and/or is it something that OpenSC should
be able to deal with?
------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
https://lists.sourceforge.net/lists/listinfo/opensc-devel

[David Woodhouse]

Post by Douglas E Engert
The auth cert is used for authentication to web sites and logins,
The encrypt cert/key is for encryption,
the card auth cert is so the card can authenticate itself, and does not require the PIN.
The sign cert/key is used to sign e-mail and such,
for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
as defined in NIST 800-73-3.

Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',
and if I import keys into any other slots, they don't:

[***@i7 tool]$ ./yubico-piv-tool -a import-key -s 9e -p $PASSPHRASE -i ~/.cert/certificate.p12 -K PKCS12
Successfully imported a new private key.
[***@i7 tool]$ p11tool --provider /usr/lib64/pkcs11/opensc-pkcs11.so --list-privkeys --login
open /home/dwmw2/pcsc-spy failed: No such file or directory
Token 'PIV_II (PIV Card Holder pin)' with URL 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29' requires user PIN
Enter PIN:
Object 0:
URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-type=private
Type: Private key
Label: SIGN key
Flags: CKA_PRIVATE; CKA_SENSITIVE;
ID: 02


I still only have the 'SIGN key'. Am I doing something (else) wrong?

Post by Douglas E Engert
So the problem it to get that second C_Login to work.
userType = CKU_USER
should be
userType = CKU_CONTEXT_SPECIFIC

That does seem to do the trick; thanks. This hack against GnuTLS now
lets me authenticate successfully to the server:

diff --git a/lib/pkcs11.c b/lib/pkcs11.c
index 630928a..a259a7e 100644
--- a/lib/pkcs11.c
+++ b/lib/pkcs11.c
@@ -2227,8 +2227,9 @@ pkcs11_login(struct pkcs11_session_info *sinfo,
if (rv == CKR_OK
&& (session_info.state == CKS_RO_USER_FUNCTIONS
|| session_info.state == CKS_RW_USER_FUNCTIONS)) {
- ret = 0;
- goto cleanup;
+ user_type = CKU_CONTEXT_SPECIFIC;
+// ret = 0;
+// goto cleanup;
}

/* If login has been attempted once already, check the token

[David Woodhouse]

Post by David Woodhouse

Post by Douglas E Engert
The auth cert is used for authentication to web sites and logins,
The encrypt cert/key is for encryption,
the card auth cert is so the card can authenticate itself, and does not require the PIN.
The sign cert/key is used to sign e-mail and such,
for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
as defined in NIST 800-73-3.

Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',

Aha. I cannot import my *certificate* usefully, as it's larger than the
2048 bytes which the device will store. But if I store some arbitrary
*other* certificate in the certificate slot corresponding to the key,
*then* the key becomes visible.

But actually, the certificate can't be *entirely* arbitrarily chosen
because otherwise I get:

17: C_SignInit
2014-11-07 00:25:35.305
[in] hSession = 0x1950820
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x184f3a0
Returned: 99 CKR_KEY_TYPE_INCONSISTENT
Error signing test data with private key: PKCS #11 error in key

I had evidently done this for the 'SIGN key' slot and had even got lucky
by importing a certificate that sufficiently matches my key. Otherwise
I'd have got stuck on that CKR_KEY_TYPE_INCONSISTENT error much
sooner :)

Should I just be generating a trivial self-signed cert with the key in
question?

[Douglas E Engert]

Post by David Woodhouse

Post by David Woodhouse

Post by Douglas E Engert
The auth cert is used for authentication to web sites and logins,
The encrypt cert/key is for encryption,
the card auth cert is so the card can authenticate itself, and does not require the PIN.
The sign cert/key is used to sign e-mail and such,
for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
as defined in NIST 800-73-3.

Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',

Aha. I cannot import my *certificate* usefully, as it's larger than the
2048 bytes which the device will store. But if I store some arbitrary
*other* certificate in the certificate slot corresponding to the key,
*then* the key becomes visible.

The PIV supports gziped certificates, that might get you some space.

From a script to write a certificate:

if [ $ZIP -eq 1 ] ; then
openssl x509 -in cards/$1.cert.$KEYID.pem \
-outform DER -out cards/$1.cert.$KEYID.der
gzip -c cards/$1.cert.$KEYID.der > cards/$1.cert.$KEYID.gz
$OPENSC_BIN/piv-tool -A "$PIV_AUTH" -Z $KEYID -i cards/$1.cert.$KEYID.gz
else
$OPENSC_BIN/piv-tool -A "$PIV_AUTH" -C $KEYID -i cards/$1.cert.$KEYID.pem

If you find gzip will make your cert much smaller then a der version of the cert
let me know, and I can give you more details.

Post by David Woodhouse
But actually, the certificate can't be *entirely* arbitrarily chosen

True,
The PIV stores private keys and certificates, but not public keys, but the only way to find out
the public key is to read the certificate to get the public key, and thus the modulus and size.
The only wayto find the modulus and size of the private key is from the public key.
This is what OpenSC does internally. And in the PKCS#11 interface will show the public key,
and the modulus, exponent and size of the private key.

Post by David Woodhouse
17: C_SignInit
2014-11-07 00:25:35.305
[in] hSession = 0x1950820
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x184f3a0
Returned: 99 CKR_KEY_TYPE_INCONSISTENT
Error signing test data with private key: PKCS #11 error in key
I had evidently done this for the 'SIGN key' slot and had even got lucky
by importing a certificate that sufficiently matches my key. Otherwise
I'd have got stuck on that CKR_KEY_TYPE_INCONSISTENT error much
sooner :)
Should I just be generating a trivial self-signed cert with the key in
question?

[David Woodhouse]

Post by Douglas E Engert
The PIV supports gziped certificates, that might get you some space.
...
If you find gzip will make your cert much smaller then a der version of the cert
let me know, and I can give you more details.

Yes, gzip reduces it from 2167 bytes to 1420, which would fit. Rather
than trying to work out how to get the OpenSC piv-tool to authenticate,
I just patched their yubico-piv-tool to handle compressed certs:
http://david.woodhou.se/yubico-piv-compress.patch

I can now happily import my real certificate into all four available
slots. And now, three of the four slots are working properly (although
the Digital Signature slot needs that GnuTLS hack to handle the login).
All I need to do is add -c "pkcs11:manufacturer=piv_II;id=%04" to the
VPN client command line it Just Works. Thanks!

Only the the Key Management slot isn't working. Is that an expected
limitation? I get this:

35: C_SignInit
2014-11-07 10:20:24.856
[in] hSession = 0xece020
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x1419230
Returned: 99 CKR_KEY_TYPE_INCONSISTENT
Error signing test data with private key: PKCS #11 error in key

[Douglas E Engert]

Post by David Woodhouse

Post by Douglas E Engert
The PIV supports gziped certificates, that might get you some space.
...
If you find gzip will make your cert much smaller then a der version of the cert
let me know, and I can give you more details.

Yes, gzip reduces it from 2167 bytes to 1420, which would fit. Rather
than trying to work out how to get the OpenSC piv-tool to authenticate,
http://david.woodhou.se/yubico-piv-compress.patch
I can now happily import my real certificate into all four available
slots. And now, three of the four slots are working properly (although
the Digital Signature slot needs that GnuTLS hack to handle the login).

That is expected. NIST 800-73-3 says the card will enforce that.
(pkcs#15 calls it user_consent, PKCS#11 its called CKA_ALWAYS_AUTHENTICATE)

Post by David Woodhouse
All I need to do is add -c "pkcs11:manufacturer=piv_II;id=%04" to the
VPN client command line it Just Works. Thanks!
Only the the Key Management slot isn't working. Is that an expected
limitation?

No.

Post by David Woodhouse
35: C_SignInit
2014-11-07 10:20:24.856
[in] hSession = 0xece020
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x1419230
Returned: 99 CKR_KEY_TYPE_INCONSISTENT
Error signing test data with private key: PKCS #11 error in key

It sounds like the cert and key don't match. It could be an import issue
or the way you built the p12 file, with mismatched cert and key.

Do you have a opensc-debug.log of the import?

did you do a login before trying to use it?

NIST 800-73-3 says the 9E key does not require login to be used.
It may be a bug in the Yubico card or OpenSC.

Do you have a opensc-debug.log of trying it?

[David Woodhouse]

Post by David Woodhouse
Only the the Key Management slot isn't working. Is that an expected
limitation?

No.

Inspired by https://www.opensc-project.org/opensc/ticket/325 I found
that this 'fixes' it:

diff --git a/src/libopensc/pkcs15-piv.c b/src/libopensc/pkcs15-piv.c
index 7f46598..57f8efa 100644
--- a/src/libopensc/pkcs15-piv.c
+++ b/src/libopensc/pkcs15-piv.c
@@ -511,7 +511,7 @@ static int sc_pkcs15emu_piv_init(sc_pkcs15_card_t *p15card)
SC_PKCS15_PRKEY_USAGE_NONREPUDIATION,
"", 0x9C, "1", SC_PKCS15_CO_FLAG_PRIVATE, 1},
{ "3", "KEY MAN key",
- /*RSA*/SC_PKCS15_PRKEY_USAGE_DECRYPT | SC_PKCS15_PRKEY_USAGE_UNWRAP,
+ /*RSA*/SC_PKCS15_PRKEY_USAGE_DECRYPT | SC_PKCS15_PRKEY_USAGE_UNWRAP | SC_PKCS15_PRKEY_USAGE_SIGN,
/*EC*/SC_PKCS15_PRKEY_USAGE_DERIVE,
"", 0x9D, "1", SC_PKCS15_CO_FLAG_PRIVATE, 0},
{ "4", "CARD AUTH key",

[Douglas E Engert]

Post by David Woodhouse

Post by Douglas E Engert
The PIV supports gziped certificates, that might get you some space.
...
If you find gzip will make your cert much smaller then a der version of the cert
let me know, and I can give you more details.

Yes, gzip reduces it from 2167 bytes to 1420, which would fit. Rather
than trying to work out how to get the OpenSC piv-tool to authenticate,
http://david.woodhou.se/yubico-piv-compress.patch

I see you have a pull request to Yubico as a patch?

NIST 800-73-3 part 1 after Table 38 refers to it as "GZIP compression" as
opposed to IsX509 compression (IsX509 is define, but not used.)

Could you change your patch to use GZIP or GZIPPED as the parameter
to clarify what is going on and add a comment about gziped of DER encode certificate?

Post by David Woodhouse
I can now happily import my real certificate into all four available
slots. And now, three of the four slots are working properly (although
the Digital Signature slot needs that GnuTLS hack to handle the login).
All I need to do is add -c "pkcs11:manufacturer=piv_II;id=%04" to the
VPN client command line it Just Works. Thanks!
Only the the Key Management slot isn't working. Is that an expected
35: C_SignInit
2014-11-07 10:20:24.856
[in] hSession = 0xece020
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x1419230
Returned: 99 CKR_KEY_TYPE_INCONSISTENT
Error signing test data with private key: PKCS #11 error in key

[David Woodhouse]

Post by Douglas E Engert
I see you have a pull request to Yubico as a patch?
NIST 800-73-3 part 1 after Table 38 refers to it as "GZIP
compression" as
opposed to IsX509 compression (IsX509 is define, but not used.)
Could you change your patch to use GZIP or GZIPPED as the parameter
to clarify what is going on and add a comment about gziped of DER encode certificate?

Will do. And in fact I may just make it automatically gzip certificates
which are too large. This stuff is enough of a twisty maze already
without making the user jump through *extra* hoops :)

[Douglas E Engert]

Post by David Woodhouse

Post by Douglas E Engert
I see you have a pull request to Yubico as a patch?
NIST 800-73-3 part 1 after Table 38 refers to it as "GZIP
compression" as
opposed to IsX509 compression (IsX509 is define, but not used.)
Could you change your patch to use GZIP or GZIPPED as the parameter
to clarify what is going on and add a comment about gziped of DER encode certificate?

Will do. And in fact I may just make it automatically gzip certificates
which are too large. This stuff is enough of a twisty maze already
without making the user jump through *extra* hoops :)

Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
IE->Tools->Internet options->Content->Certificates->Personal should show the certificates
It should work, but try it just in case. Note you will need a CHUID on the NEO. The
yubico-piv-tool can creat the CHUID.

[David Woodhouse]

Post by Douglas E Engert

Post by David Woodhouse
Will do. And in fact I may just make it automatically gzip certificates
which are too large. This stuff is enough of a twisty maze already
without making the user jump through *extra* hoops :)

Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
IE->Tools->Internet options->Content->Certificates->Personal should show the certificates
It should work, but try it just in case. Note you will need a CHUID on the NEO. The
yubico-piv-tool can creat the CHUID.

Access to a Windows box for that would be non-trivial. Given that the
choices here are to compress or to fail outright, it's not clear that
'compress' could ever be the wrong choice, could it?

But I have to run for now, so I won't be doing that today anyway.

Are you happier with this version of the patch?

https://github.com/dwmw2/yubico-piv-tool/commit/dca2cb029ec4b983b193c617ee4095ad041cc8a6

[Douglas E Engert]

Post by David Woodhouse

Post by Douglas E Engert

Post by David Woodhouse
Will do. And in fact I may just make it automatically gzip certificates
which are too large. This stuff is enough of a twisty maze already
without making the user jump through *extra* hoops :)

Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
IE->Tools->Internet options->Content->Certificates->Personal should show the certificates
It should work, but try it just in case. Note you will need a CHUID on the NEO. The
yubico-piv-tool can creat the CHUID.

Access to a Windows box for that would be non-trivial. Given that the
choices here are to compress or to fail outright, it's not clear that
'compress' could ever be the wrong choice, could it?
But I have to run for now, so I won't be doing that today anyway.
Are you happier with this version of the patch?
https://github.com/dwmw2/yubico-piv-tool/commit/dca2cb029ec4b983b193c617ee4095ad041cc8a6

Actually no.

card-piv.c has when reading:

1037 tag = sc_asn1_find_tag(card->ctx, body, bodylen, 0x71, &taglen);
1038 /* 800-72-1 not clear if this is 80 or 01 Sent comment to NIST for 800-72-2 */
1039 if (tag && (((*tag) & 0x80) || ((*tag) & 0x01))) {
1040 compressed = 1;
1041 }

And when writing it has:

1244 *p++ = (flags)? 0x80:0x00; /* certinfo, i.e. gziped? */

But NIST 800-73-3 Part 1 clarified it:

After table 38:
"For a certificate encoded using GZIP compression CertInfo shall be '0x01'.

Looking at the TLV for the compress flag in a certificate object from a NIST demo card, shows 71 01 01

SO the OpenSC code will read either, but it is writing it wrong.
it should do this.

1244 *p++ = (flags)? 0x01:0x00; /* certinfo, i.e. gziped? */

You patch is also writing it wrong it has:


*certptr++ = compress << 7; /* certinfo (gzip etc) */
it should have:
*certptr++ = compress; /* certinfo (gzip etc) */
or
*certptr++ = compress? 0x01:0x00; /* certinfo (gzip etc) */


Writing it wrong could cause cert to not work using Microsoft's PIV driver,
if it does not test for both.

I will fix OpenSC.

[David Woodhouse]

Post by Douglas E Engert
1244 *p++ = (flags)? 0x80:0x00; /* certinfo, i.e. gziped? */
*certptr++ = compress << 7; /* certinfo (gzip etc) */

Right. I was looking at what OpenSC did. Will fix. Thanks for reviewing
it.

[David Woodhouse]

Post by Douglas E Engert

Post by David Woodhouse

Post by Douglas E Engert
I see you have a pull request to Yubico as a patch?
NIST 800-73-3 part 1 after Table 38 refers to it as "GZIP
compression" as
opposed to IsX509 compression (IsX509 is define, but not used.)
Could you change your patch to use GZIP or GZIPPED as the parameter
to clarify what is going on and add a comment about gziped of DER encode certificate?

Will do. And in fact I may just make it automatically gzip certificates
which are too large. This stuff is enough of a twisty maze already
without making the user jump through *extra* hoops :)

Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
IE->Tools->Internet options->Content->Certificates->Personal should show the certificates
It should work, but try it just in case. Note you will need a CHUID on the NEO. The
yubico-piv-tool can creat the CHUID.

Nice. Every time I assign the USB device to the Windows VM, Windows goes
off and looks for a driver update in Windows Update for a period of many
minutes before installing the driver (again) and claiming that the
device is working.

But even if I put uncompressed certs in, they never appear in the UI you
guided me to or in certmgr.msc. I did create a CHUID.

I think I've had about as much of Windows as I can stand for today.

[Douglas E Engert]

Post by David Woodhouse

Post by Douglas E Engert

Post by David Woodhouse

Post by Douglas E Engert
I see you have a pull request to Yubico as a patch?
NIST 800-73-3 part 1 after Table 38 refers to it as "GZIP
compression" as
opposed to IsX509 compression (IsX509 is define, but not used.)
Could you change your patch to use GZIP or GZIPPED as the parameter
to clarify what is going on and add a comment about gziped of DER encode certificate?

Will do. And in fact I may just make it automatically gzip certificates
which are too large. This stuff is enough of a twisty maze already
without making the user jump through *extra* hoops :)

Try a gziped cert with Windows 7 or 8 first, using Microsoft's built in PIV driver first.
IE->Tools->Internet options->Content->Certificates->Personal should show the certificates
It should work, but try it just in case. Note you will need a CHUID on the NEO. The
yubico-piv-tool can creat the CHUID.

Nice. Every time I assign the USB device to the Windows VM, Windows goes
off and looks for a driver update in Windows Update for a period of many
minutes before installing the driver (again) and claiming that the
device is working.
But even if I put uncompressed certs in, they never appear in the UI you
guided me to or in certmgr.msc. I did create a CHUID.

They can't be self signed...


https://developers.yubico.com/yubico-piv-tool/Windows-Certificate.html
claims it will work with Windows.

Before I retired, I did have a Yubico NEO at work and I believe I tested it on Windows.
The cert was signed by our Microsoft enterprise CA.

Post by David Woodhouse
I think I've had about as much of Windows as I can stand for today.

Well, take the weekend off. I am.
I have a new NEO, I will look at it next week.

[David Woodhouse]

Post by Douglas E Engert

Post by David Woodhouse
I think I've had about as much of Windows as I can stand for today.

Well, take the weekend off. I am.

Good idea :)

Btw, on the misbehaviour of the Key Management slot — was it sufficient
to observe that adding SC_PKCS12_PRKEY_USAGE_SIGN makes it happy, or did
you still want to the debug logs that you asked for?

Other than that, I think we fairly much have a handle on all the issues
I've seen.

Post by Douglas E Engert
I have a new NEO, I will look at it next week.

Have fun :)

I'm going to take a look at using the ykneo-oath applet to provide
TOTP/HOTP support (I already support libpskc/liboath).

[Douglas E Engert]

Post by David Woodhouse

Post by Douglas E Engert

Post by David Woodhouse
I think I've had about as much of Windows as I can stand for today.

Well, take the weekend off. I am.

Good idea :)
Btw, on the misbehaviour of the Key Management slot — was it sufficient
to observe that adding SC_PKCS12_PRKEY_USAGE_SIGN makes it happy, or did
you still want to the debug logs that you asked for?

Actually, the PIV has three user cert/keys designed for specific usages with specific
access patterns. The Key Management key is for encryption or derivation,
the auth key is for authentiction, and the signing key is to sign e-mail and documents.

The Key Management is not for signing.
See NIST 800-73-3 Part 1:
3.2.4 X.509 Certificate for Key Management

Note it must be escrowed too...

But pkcs15-piv.c already has this:

978 /*
979 * When no cert is present and a pubkey in a file was found,
980 * means the caller is initilaizeing a card. A sign operation
981 * will be required to sign a certificate request even if
982 * normal usage would not allow it. Set SC_PKCS15_PRKEY_USAGE_SIGN
983 * TODO if code is added to allow key generation and reqest
984 * sign in the same session, similiar code will be needed.
985 */
986
987 if (ckis[i].pubkey_from_file == 1) {
988 prkey_info.usage = SC_PKCS15_PRKEY_USAGE_SIGN;
989 sc_debug(card->ctx, SC_LOG_DEBUG_NORMAL, "Adding SC_PKCS15_PRKEY_USAGE_SIGN");
990 }
991

See:
https://github.com/OpenSC/OpenSC/wiki/PivTool

"Generate a "certificate request" and "Clear a certificate on the card"

Post by David Woodhouse
Other than that, I think we fairly much have a handle on all the issues
I've seen.

Post by Douglas E Engert
I have a new NEO, I will look at it next week.

Have fun :)
I'm going to take a look at using the ykneo-oath applet to provide
TOTP/HOTP support (I already support libpskc/liboath).

[Douglas E Engert]

Post by David Woodhouse

Post by David Woodhouse

Post by Douglas E Engert
The auth cert is used for authentication to web sites and logins,
The encrypt cert/key is for encryption,
the card auth cert is so the card can authenticate itself, and does not require the PIN.
The sign cert/key is used to sign e-mail and such,
for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
as defined in NIST 800-73-3.

Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',

Aha. I cannot import my *certificate* usefully, as it's larger than the
2048 bytes which the device will store. But if I store some arbitrary
*other* certificate in the certificate slot corresponding to the key,
*then* the key becomes visible.
But actually, the certificate can't be *entirely* arbitrarily chosen
17: C_SignInit
2014-11-07 00:25:35.305
[in] hSession = 0x1950820
pMechanism->type=CKM_RSA_PKCS
[in] hKey = 0x184f3a0
Returned: 99 CKR_KEY_TYPE_INCONSISTENT
Error signing test data with private key: PKCS #11 error in key
I had evidently done this for the 'SIGN key' slot and had even got lucky
by importing a certificate that sufficiently matches my key. Otherwise
I'd have got stuck on that CKR_KEY_TYPE_INCONSISTENT error much
sooner :)
Should I just be generating a trivial self-signed cert with the key in
question?

You could. Or see the comments about using gzip and writing the certificate
with the OpenSC pkcs11-tool

Thier docs:
https://developers.yubico.com/yubico-piv-tool/YubiKey-NEO-PIV-Introduction.html

says 2005 is max object size. A certificate object has about 20 bytes of extra overhead.

[Douglas E Engert]

Post by David Woodhouse

Post by Douglas E Engert
The auth cert is used for authentication to web sites and logins,
The encrypt cert/key is for encryption,
the card auth cert is so the card can authenticate itself, and does not require the PIN.
The sign cert/key is used to sign e-mail and such,
for this cert/key. (So it is not clear if you are using the correct cert/key for the intended use,
as defined in NIST 800-73-3.

Perhaps so. But this one actually shows up in 'p11tool --list-privkeys',

You would have to ask Yubico, why you can not import the other keys, as this is their tool.

What version of the NEO do you have?
On 10/30/14 their rep said:
"The one we currently ship is version 0.1.2 fixes since 0.1.0 is related to import with ecc and rsa1024."



The NIST 800-73-3 defines the user interface, and some minimal commands to generate a key on the card,
and put-data to write objests to teh card. But for card management, NIST left that up to the vendors.
OpenSC implements the user interface to the PIV card, and the card management commands listed in 800-73.3.

(With 800-73-3 their can be more keys on the card, older encryption keys...)

Post by David Woodhouse
Successfully imported a new private key.
open /home/dwmw2/pcsc-spy failed: No such file or directory
Token 'PIV_II (PIV Card Holder pin)' with URL 'pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29' requires user PIN
URL: pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=00000000;token=PIV_II%20%28PIV%20Card%20Holder%20pin%29;id=%02;object=SIGN%20key;object-type=private
Type: Private key
Label: SIGN key
Flags: CKA_PRIVATE; CKA_SENSITIVE;
ID: 02
I still only have the 'SIGN key'. Am I doing something (else) wrong?

Post by Douglas E Engert
So the problem it to get that second C_Login to work.
userType = CKU_USER
should be
userType = CKU_CONTEXT_SPECIFIC

That does seem to do the trick; thanks. This hack against GnuTLS now
diff --git a/lib/pkcs11.c b/lib/pkcs11.c
index 630928a..a259a7e 100644
--- a/lib/pkcs11.c
+++ b/lib/pkcs11.c
@@ -2227,8 +2227,9 @@ pkcs11_login(struct pkcs11_session_info *sinfo,
if (rv == CKR_OK
&& (session_info.state == CKS_RO_USER_FUNCTIONS
|| session_info.state == CKS_RW_USER_FUNCTIONS)) {
- ret = 0;
- goto cleanup;
+ user_type = CKU_CONTEXT_SPECIFIC;
+// ret = 0;
+// goto cleanup;
}
/* If login has been attempted once already, check the token

[David Woodhouse]

Post by Douglas E Engert
So the problem it to get that second C_Login to work.
userType = CKU_USER
should be
userType = CKU_CONTEXT_SPECIFIC
PKCS#11 2.20 section 10.9
Re-authentication occurs by calling C_Login with userType set to
CKU_CONTEXT_SPECIFIC immediately after a cryptographic operation using the
key has been initiated (e.g. after C_SignInit). In this call, the actual user type is
implicitly given by the usage requirements of the active key. If C_Login returns
CKR_OK the user was successfully authenticated and this sets the active key in an
authenticated state that lasts until the cryptographic operation has successfully or
unsuccessfully been completed (e.g. by C_Sign, C_SignFinal,..).

Going back to this... my application (using the p11-kit callbacks) will
currently provide the *same* PIN for the CKU_CONTEXT_SPECIFIC login, as
the user already provided for the CKU_USER login. Which works here, but
is it the right thing to do?

If invoked *again* with the P11_KIT_PIN_FLAGS_RETRY flag set, the
application will forget the previous PIN and ask the user again.