Re: PKCS#11 module: C_GetAttributeValue problems
Guys, I figured out that Thunderbird didn't like this assignment of CKA_TOKEN when assigning the values (with the buffers of right sizes already allocated): > > pTemplate[i].pValue = (CK_BBOOL *)TRUE; > > (but it compiled fine). I changed it to > > *((CK_BBOOL *)pTemplate[i].pValue) = TRUE; Oh, yes, The first line would definitely cause a crash;). > > and it works perfectly! I am pretty n00b at C++ (well, still > learning). I will avoid this mistake in the future. Thanks again for > your willing to help :) > > M. Kurpel -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 module: C_GetAttributeValue problems
Dňa 13. 8. 2010 18:35, Robert Relyea wrote / napísal(a): On 08/13/2010 05:37 AM, Konstantin Andreev wrote: On 08/13/10 04:44, Robert Relyea wrote: On Wed, Aug 11, 2010 at 1:18 PM, Matej Kurpel wrote: [ ... skip ... ] Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives zero-sized buffers for both values. ... According to the specification (if I understood correctly), I should return CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the two attribute values, which makes perfect sense. No, you need to return CKR_OK. You only return CKR_BUFFER_TOO_SMALL if a buffer was supplied and it didn't fit (in which case you set the offending attribute length to -1). See the PKCS #11 spec for C_GetAttributeValue. By returning CKR_BUFFER_TOO_SMALL to NSS, you are telling it that the requested operation failed (That operation was to get the lengths of the attributes it wanted to read). Hello, Robert. Matej told us that buffers were supplied, but zero-size. He didn't tell that buffers were NULL. Ah, that case CKR_BUFFER_TOO_SMALL would be appriopriate. I'm pretty sure that that was not the case. I suspect he didn't check for NULL since I know of no where in NSS that would do such a thing, but I know exactly where we are asking for CKA_TOKEN and CKA_LABEL with a NULL buffer. see http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11obj.c#210 I am not sure, whether this applies to Matej issue, but PK11_GetAttributes is defective. It doesn't care about nullifying CK_ATTRIBUTE::pValue before 1st call to C_GetAttributeValue. The caller of PK11_GetAttributes should care about. Yes, it does require the caller to set things to NULL first.. bob -- Konstantin. Guys, I figured out that Thunderbird didn't like this assignment of CKA_TOKEN when assigning the values (with the buffers of right sizes already allocated): pTemplate[i].pValue = (CK_BBOOL *)TRUE; (but it compiled fine). I changed it to *((CK_BBOOL *)pTemplate[i].pValue) = TRUE; and it works perfectly! I am pretty n00b at C++ (well, still learning). I will avoid this mistake in the future. Thanks again for your willing to help :) M. Kurpel -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 module: C_GetAttributeValue problems
On 08/13/2010 05:37 AM, Konstantin Andreev wrote: > On 08/13/10 04:44, Robert Relyea wrote: >>> On Wed, Aug 11, 2010 at 1:18 PM, Matej Kurpel >>> wrote: >>> [ ... skip ... ] Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives zero-sized buffers for both values. ... According to the specification (if I understood correctly), I should return CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the two attribute values, which makes perfect sense. >>> >> No, you need to return CKR_OK. You only return CKR_BUFFER_TOO_SMALL >> if a buffer was supplied and it didn't fit (in which case you set the >> offending attribute length to -1). See the PKCS #11 spec for >> C_GetAttributeValue. >> >> By returning CKR_BUFFER_TOO_SMALL to NSS, you are telling it that the >> requested operation failed (That operation was to get the lengths of >> the attributes it wanted to read). >> > > Hello, Robert. > > Matej told us that buffers were supplied, but zero-size. He didn't > tell that buffers were NULL. Ah, that case CKR_BUFFER_TOO_SMALL would be appriopriate. I'm pretty sure that that was not the case. I suspect he didn't check for NULL since I know of no where in NSS that would do such a thing, but I know exactly where we are asking for CKA_TOKEN and CKA_LABEL with a NULL buffer. > >> see >> http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11obj.c#210 >> >> > > I am not sure, whether this applies to Matej issue, but > PK11_GetAttributes is defective. It doesn't care about nullifying > CK_ATTRIBUTE::pValue before 1st call to C_GetAttributeValue. The > caller of PK11_GetAttributes should care about. Yes, it does require the caller to set things to NULL first.. bob > > -- > Konstantin. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re[6]: PKCS#11 module: C_GetAttributeValue problems
On 08/13/10 04:44, Robert Relyea wrote: On Wed, Aug 11, 2010 at 1:18 PM, Matej Kurpel wrote: [ ... skip ... ] Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives zero-sized buffers for both values. ... According to the specification (if I understood correctly), I should return CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the two attribute values, which makes perfect sense. No, you need to return CKR_OK. You only return CKR_BUFFER_TOO_SMALL if a buffer was supplied and it didn't fit (in which case you set the offending attribute length to -1). See the PKCS #11 spec for C_GetAttributeValue. By returning CKR_BUFFER_TOO_SMALL to NSS, you are telling it that the requested operation failed (That operation was to get the lengths of the attributes it wanted to read). Hello, Robert. Matej told us that buffers were supplied, but zero-size. He didn't tell that buffers were NULL. see http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11obj.c#210 I am not sure, whether this applies to Matej issue, but PK11_GetAttributes is defective. It doesn't care about nullifying CK_ATTRIBUTE::pValue before 1st call to C_GetAttributeValue. The caller of PK11_GetAttributes should care about. -- Konstantin. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 module: C_GetAttributeValue problems
On 08/11/2010 09:53 PM, Wan-Teh Chang wrote: > On Wed, Aug 11, 2010 at 1:18 PM, Matej Kurpel wrote: > >> Hello, >> I am trying to implement a PKCS#11 module for my diploma thesis. It is >> intended to be used with thunderbird. I am using opensc pkcs11-spy module to >> debug it. I have a problem for quite some days I don't seem to be able to >> solve myself. >> At first, thunderbird searches for token certificates >> (CKA_CLASS=CKO_CERTIFICATE and CKA_TOKEN=TRUE). I am returning an object >> with handle 0x1 (letting thunderbird know I have such a certificate). Later, >> thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives >> zero-sized buffers for both values. This is where my problem lies - I don't >> know what to return and if I have to fill the values in the template or not. >> According to the specification (if I understood correctly), I should return >> CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the >> two attribute values, which makes perfect sense. >> > I think this is correct. > > I don't know why Thunderbird doesn't call C_GetAttributeValue again > with the right buffer sizes. > No, you need to return CKR_OK. You only return CKR_BUFFER_TOO_SMALL if a buffer was supplied and it didn't fit (in which case you set the offending attribute length to -1). See the PKCS #11 spec for C_GetAttributeValue. By returning CKR_BUFFER_TOO_SMALL to NSS, you are telling it that the requested operation failed (That operation was to get the lengths of the attributes it wanted to read). see: http://mxr.mozilla.org/security/source/security/nss/lib/pk11wrap/pk11obj.c#210 It shouldn't be crashing (at least not before calling C_GetAttributeValue again). There's an option to run thunderbird under a debugger. A stack traceback at the point of crash will tell a lot (as Konstantin pointed out). bob > Wan-Teh > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re[5]: PKCS#11 module: C_GetAttributeValue problems
On 08/12/10 14:26, Matej Kurpel wrote: Dňa 12. 8. 2010 11:03, Konstantin Andreev wrote / napísal(a): On 08/12/10 00:18, Matej Kurpel wrote: [ ... skip ...] Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives zero-sized buffers for both values. This is where my problem lies - I don't know what to return and if I have to fill the values in the template or not. According to the specification (if I understood correctly), I should return CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the two attribute values, which makes perfect sense. Could you, please, provide stack trace at this point ? Which versions of NSS and Thunderbird you are using ? How do I get stack trace, please? I am using the latest stable release of Thunderbird (3.1.2) which I am normally using. Even better... As far as you are developer, you could investigate the problem yourself for a bit. Live with stock Thunderbird, but build debug version of NSS. Run TB against built NSS, and let your interactive debugger break at the moment where TB calls C_GetAttributeValue with zero-sized buffers. Then walk the stack trace and you will quickly isolate the fault point. -- Konstantin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 module: C_GetAttributeValue problems
Dňa 12. 8. 2010 11:03, Konstantin Andreev wrote / napísal(a): On 08/12/10 00:18, Matej Kurpel wrote: [ ... skip ...] Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives zero-sized buffers for both values. This is where my problem lies - I don't know what to return and if I have to fill the values in the template or not. According to the specification (if I understood correctly), I should return CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the two attribute values, which makes perfect sense. Could you, please, provide stack trace at this point ? Which versions of NSS and Thunderbird you are using ? How do I get stack trace, please? I am using the latest stable release of Thunderbird (3.1.2) which I am normally using. Then thunderbird should ask for the values again (by calling C_GetAttributeValue again), but with the right buffer sizes. The problem is that it does not. -- Konstantin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re[2]: PKCS#11 module: C_GetAttributeValue problems
On 08/12/10 00:18, Matej Kurpel wrote: [ ... skip ...] Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives zero-sized buffers for both values. This is where my problem lies - I don't know what to return and if I have to fill the values in the template or not. According to the specification (if I understood correctly), I should return CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the two attribute values, which makes perfect sense. Could you, please, provide stack trace at this point ? Which versions of NSS and Thunderbird you are using ? Then thunderbird should ask for the values again (by calling C_GetAttributeValue again), but with the right buffer sizes. The problem is that it does not. -- Konstantin -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: PKCS#11 module: C_GetAttributeValue problems
On Wed, Aug 11, 2010 at 1:18 PM, Matej Kurpel wrote: > Hello, > I am trying to implement a PKCS#11 module for my diploma thesis. It is > intended to be used with thunderbird. I am using opensc pkcs11-spy module to > debug it. I have a problem for quite some days I don't seem to be able to > solve myself. > At first, thunderbird searches for token certificates > (CKA_CLASS=CKO_CERTIFICATE and CKA_TOKEN=TRUE). I am returning an object > with handle 0x1 (letting thunderbird know I have such a certificate). Later, > thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives > zero-sized buffers for both values. This is where my problem lies - I don't > know what to return and if I have to fill the values in the template or not. > According to the specification (if I understood correctly), I should return > CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the > two attribute values, which makes perfect sense. I think this is correct. I don't know why Thunderbird doesn't call C_GetAttributeValue again with the right buffer sizes. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
PKCS#11 module: C_GetAttributeValue problems
Hello, I am trying to implement a PKCS#11 module for my diploma thesis. It is intended to be used with thunderbird. I am using opensc pkcs11-spy module to debug it. I have a problem for quite some days I don't seem to be able to solve myself. At first, thunderbird searches for token certificates (CKA_CLASS=CKO_CERTIFICATE and CKA_TOKEN=TRUE). I am returning an object with handle 0x1 (letting thunderbird know I have such a certificate). Later, thunderbird asks for its attributes CKA_TOKEN and CKA_LABEL but gives zero-sized buffers for both values. This is where my problem lies - I don't know what to return and if I have to fill the values in the template or not. According to the specification (if I understood correctly), I should return CKR_BUFFER_TOO_SMALL and fill the ulValueLen properties to the length of the two attribute values, which makes perfect sense. Then thunderbird should ask for the values again (by calling C_GetAttributeValue again), but with the right buffer sizes. The problem is that it does not. It only tries to find token objects with CKA_CLASS CKO_NETSCAPE_TRUST and then some CKO_NETSCAPE_CRLs, that is all. I found some examples on the internet, where instead of CKR_BUFFER_TOO_SMALL they return CKR_OK and everything works. For me it does not - as soon as I return CKR_OK, thunderbird crashes after leaving C_GetAttributeValue with the zero-sized buffers. So what should I do? I am really at loss now. I am attaching the appropriate part of the logs. Thanks for all responses. (PKCS11-SPY LOG BEGIN; uninteresting items omitted) 11: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate[2]: CKA_TOKEN True CKA_CLASS CKO_CERTIFICATE Returned: 0 CKR_OK 12: C_FindObjects [in] hSession = 0x1 [in] ulMaxObjectCount = 0xa [out] ulObjectCount = 0x1 Object 1 Matches Returned: 0 CKR_OK 13: C_FindObjectsFinal [in] hSession = 0x1 Returned: 0 CKR_OK 14: C_GetAttributeValue [in] hSession = 0x1 [in] hObject = 0x1 [in] pTemplate[2]: CKA_TOKEN requested with 0 buffer CKA_LABEL requested with 0 buffer [out] pTemplate[2]: CKA_TOKEN has size 1 CKA_LABEL has size 41 Returned: 336 CKR_BUFFER_TOO_SMALL 15: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate[2]: CKA_TOKEN True CKA_CLASS CKO_NETSCAPE_TRUST Returned: 19 CKR_ATTRIBUTE_VALUE_INVALID 16: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate[2]: CKA_CLASS CKO_NETSCAPE_CRL CKA_SUBJECT [size : 0x48 (72)] 3046310B 30090603 55040613 02555331 13301106 0355040A 130A476F 6F676C65 20496E63 31223020 06035504 03131947 6F6F676C 6520496E 7465726E 65742041 7574686F 72697479 Returned: 19 CKR_ATTRIBUTE_VALUE_INVALID 17: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate[2]: CKA_CLASS CKO_NETSCAPE_CRL CKA_SUBJECT [size : 0x50 (80)] 304E310B 30090603 55040613 02555331 10300E06 0355040A 13074571 75696661 78312D30 2B060355 040B1324 45717569 66617820 53656375 72652043 65727469 66696361 74652041 7574686F 72697479 Returned: 19 CKR_ATTRIBUTE_VALUE_INVALID 18: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate[2]: CKA_CLASS CKO_NETSCAPE_CRL CKA_SUBJECT [size : 0xBD (189)] 3081BA31 0B300906 03550406 13025553 31173015 06035504 0A130E56 65726953 69676E2C 20496E63 2E311F30 1D060355 040B1316 56657269 5369676E 20547275 7374204E 6574776F 726B313B 30390603 55040B13 32546572 6D73206F 66207573 65206174 20687474 70733A2F 2F77 2E766572 69736967 6E2E636F 6D2F7270 61202863 29303631 34303206 03550403 132B5665 72695369 676E2043 6C617373 20332045 7874656E 64656420 56616C69 64617469 6F6E2053 534C2043 41 Returned: 19 CKR_ATTRIBUTE_VALUE_INVALID 19: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate[2]: CKA_CLASS CKO_NETSCAPE_CRL CKA_SUBJECT [size : 0xCD (205)] 3081CA31 0B300906 03550406 13025553 31173015 06035504 0A130E56 65726953 69676E2C 20496E63 2E311F30 1D060355 040B1316 56657269 5369676E 20547275 7374204E 6574776F 726B313A 30380603 55040B13 31286329 20323030 36205665 72695369 676E2C20 496E632E 202D2046 6F722061 7574686F 72697A65 64207573 65206F6E 6C793145 30430603 55040313 3C566572 69536967 6E20436C 61737320 33205075 626C6963 20507269 6D617279 20436572 74696669 63617469 6F6E2041 7574686F 72697479 202D2047 35 Returned: 19 CKR_ATTRIBUTE_VALUE_INVALID 20: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate[2]: CKA_CLASS CKO_NETSCAPE_CRL CKA_SUBJECT [size : 0x50 (80)] 304E310B 30090603 55040613 02555331 10300E06 0355040A 13074571 75696661 78312D30 2B060355 040B1324 45717569 66617820 53656375 72652043 65727469 66696361 74652041 7574686F 72697479 Returned: 19 CKR_ATTRIBUTE_VALUE_INVALID 21: C_FindObjectsInit [in] hSession = 0x1 [in] pTemplate[2]: CKA_CLASS CKO_NETS
