From gnutls-devel at lists.gnutls.org Wed Sep 5 01:33:59 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 04 Sep 2018 23:33:59 +0000 Subject: [gnutls-devel] libtasn1 | GENERIC_ERROR returned on asn1_der_coding method (#5) In-Reply-To: References: Message-ID: Found out the methods asn1_create_element has to be used instead of the output of asn1_parser2tree directly. This is a bit confusing since both functions output a 'asn1_node *'. I would recommend having 2 different types here to clarify which structure can serve as input of other functions. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/5#note_98930710 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 5 01:34:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 04 Sep 2018 23:34:00 +0000 Subject: [gnutls-devel] libtasn1 | GENERIC_ERROR returned on asn1_der_coding method (#5) In-Reply-To: References: Message-ID: Issue was closed by Flo Issue #5: https://gitlab.com/gnutls/libtasn1/issues/5 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/libtasn1/issues/5 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 5 07:20:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 05 Sep 2018 05:20:04 +0000 Subject: [gnutls-devel] GnuTLS | Valid cert fails to verify due to different DN encodings (#553) In-Reply-To: References: Message-ID: The dn comparison rules are a long sad story. Gnutls has followed the simple approach to compare dn for simple equality and that works in practice very well - noone complained since our first days. Note however that what you describe above is incorrect even according to rfc5280 comparison rules. Which implementation created that certificate? Have you reported that issue to them? https://tools.ietf.org/html/rfc5280#section-7.1 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/553#note_98956888 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Sep 7 17:04:04 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 07 Sep 2018 15:04:04 +0000 Subject: [gnutls-devel] GnuTLS | Fuzzer tests complain about missing file (#556) References: Message-ID: New Issue was created. Issue 556: https://gitlab.com/gnutls/gnutls/issues/556 Author: Tom Assignee: Tim R?hsen When I run make check then all tests pass except for the fuzzers. Looking in the logs reveals the following error for all tls-fuzzer-*.sh tests: > python: can't open file 'tests/scripts_retention.py' This file is indeed missing. The question is now, where should it come from? Should it be somewhere in the Git repo and has it been forgotten to be added? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/556 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Fri Sep 7 22:42:39 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Fri, 07 Sep 2018 20:42:39 +0000 Subject: [gnutls-devel] GnuTLS | Fuzzer tests complain about missing file (#556) In-Reply-To: References: Message-ID: It's part of a git submodule, so try ``` git submodule update --init ``` and you should see `./tests/suite/tls-fuzzer/tlsfuzzer/tests/scripts_retention.py`. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/556#note_99808253 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Sep 8 19:04:36 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 08 Sep 2018 17:04:36 +0000 Subject: [gnutls-devel] GnuTLS | gnutls-cli - incomplete DANE support (#557) References: Message-ID: New Issue was created. Issue 557: https://gitlab.com/gnutls/gnutls/issues/557 Author: Andreas Metzler Assignee: ## Description of problem: gnutls-cli DANE support is incomplete. Even when certificate usage in the TLSA record specifies "trust anchor assertion" or "domain-issued certificate" the trust check requires a match in the local trust-store. ## Version of gnutls used: 3.6.3 + git d4624761e3893314d5504a6ecbc9da6ff758bc41 (August 15 2018) Also applies to 3.5.x ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Debian/experimental ## How reproducible: Steps to Reproduce: 1. Make sure that Let's Encrypt CA is not in trust-store 2. gnutls-cli --dane lists.gentoo.org --starttls-proto=smtp < /dev/null ## Actual results: The connection fails with "The certificate is NOT trusted". ## Expected results: Successful connection. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/557 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sat Sep 8 19:22:34 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sat, 08 Sep 2018 17:22:34 +0000 Subject: [gnutls-devel] GnuTLS | Unclear extent of functionality of danetool --check (#558) References: Message-ID: New Issue was created. Issue 558: https://gitlab.com/gnutls/gnutls/issues/558 Author: Andreas Metzler Assignee: ## Description of problem: p11tool(1) says ``` --check=string Check a host's DANE TLSA entry. Obtains the DANE TLSA entry from the given hostname and prints information. Note that the actual certificate of the host can be provided using --load-certificate, otherwise danetool will connect to the server to obtain it. The exit code on verification success will be zero. ``` I understood this to mean that p11tool actually does trust verification. However afaict this is somewhere in between a syntax check and a trust path validation. I *think* p11tool uses the following steps: 1. Pull the TLSA record 2. Connect to the host and get receive the provided certificate chain. 3. Verify the server certificate using the provided certificate chain and TLSA record, i.e. - with certificate usage 0 or 2 check for a signing certificate in the chain - with certificate usage 1 or 3 check that the server cert matches the fingerprint in the TLSA record. - The local trust store is never consulted. I do understand that it might make sense to not consult the local trust-store since _gnutls-cli --dane_ already exists. ## Version of gnutls used: gnutls GIT d4624761e3893314d5504a6ecbc9da6ff758bc41 (15 Aug 2018) - post 3.6.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Debian -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/558 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Sun Sep 9 18:39:58 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Sun, 09 Sep 2018 16:39:58 +0000 Subject: [gnutls-devel] GnuTLS | certtool test fails on 3.6.3, not 3.6.2 (regression) (#560) References: Message-ID: New Issue was created. Issue 560: https://gitlab.com/gnutls/gnutls/issues/560 Author: A. Wilcox Assignee: ## Description of problem: ``` FAIL: certtool ============== Generating a 3072 bit RSA private key... Generating a self signed certificate... No PIN given. note: when operating in batch mode, set the GNUTLS_PIN or GNUTLS_SO_PIN environment variables cert generation failed FAIL certtool (exit status: 1) ``` ## Version of gnutls used: 3.6.3 ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Ad?lie Linux; I'm the maintainer of GnuTLS for Ad?lie and it was built by me. ## How reproducible: Always Steps to Reproduce: * build * `make check` ## Actual results: Test failure. ## Expected results: No test failure; 3.6.2 skipped this test. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/560 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Mon Sep 10 17:52:40 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Mon, 10 Sep 2018 15:52:40 +0000 Subject: [gnutls-devel] GnuTLS | doc: fix reference to invocation nodes (!744) References: Message-ID: New Merge Request !744 https://gitlab.com/gnutls/gnutls/merge_requests/744 Project:Branches: andreas-schwab/gnutls:master to gnutls/gnutls:master Author: Andreas Schwab Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/744 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Sep 11 09:33:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 11 Sep 2018 07:33:00 +0000 Subject: [gnutls-devel] GnuTLS | Fuzzer tests complain about missing file (#556) In-Reply-To: References: Message-ID: Issue was closed by Tim R?hsen Issue #556: https://gitlab.com/gnutls/gnutls/issues/556 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/556 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Sep 11 12:25:08 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 11 Sep 2018 10:25:08 +0000 Subject: [gnutls-devel] GnuTLS | Valid cert fails to verify due to different DN encodings (#553) In-Reply-To: References: Message-ID: > Which implementation created that certificate? It was created by the Bouncy Castle java library. Specifically the JRuby OpenSSL library (which in plain Ruby is a pretty thin OpenSSL API layer but is heavier in JRuby since the Bouncy Castle x509/SSL stuff doesn't have an OpenSSL compatible API). > Have you reported that issue to them? > https://tools.ietf.org/html/rfc5280#section-7.1 No, the cert looked correct to me. Even after reading section 7.1 that you linked, I don't see how it is incorrect. It specifically says UTF8String and PrintableString are both required to be supported. Can you give me more detail about how it violates the comparison rules? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/553#note_100329927 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Tue Sep 11 23:28:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Tue, 11 Sep 2018 21:28:23 +0000 Subject: [gnutls-devel] GnuTLS | Fuzzer tests complain about missing file (#556) In-Reply-To: References: Message-ID: Sorry for my late response. I was abroad without my dev system so I couldn't test. Your solution does indeed produce the missing file and solves the problem. How come that the bootstrap script doesn't produce this outcome? If I recall correctly it calls `git submodule update --init`. However, I ended up with the missing file. Is there something missing in the bootstrap script or was the submodule repo not up to date? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/556#note_100659281 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 12 09:07:23 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 12 Sep 2018 07:07:23 +0000 Subject: [gnutls-devel] GnuTLS | Fuzzer tests complain about missing file (#556) In-Reply-To: References: Message-ID: The bootstrap script is from gnulib and only cares for the gnulib submodule (`git submodule update --init gnulib`). Since `./bootstrap.conf` is sourced by `./bootstrap`, we could of course update the other submodules from there. @nmav WDYT (some CI runners don't update the submodules on purpose !?). -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/556#note_100720285 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 12 16:36:00 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 12 Sep 2018 14:36:00 +0000 Subject: [gnutls-devel] GnuTLS | Fuzzer tests complain about missing file (#556) In-Reply-To: References: Message-ID: Okay that's clear, thanks. I think it might be nice however to have the bootstrap script take care of everything that needs to be bootstrapped. Don't you? Lets see what Nikos has to say about this. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/556#note_100843618 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 12 17:09:46 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 12 Sep 2018 15:09:46 +0000 Subject: [gnutls-devel] GnuTLS | docs: stress the byte order in GOST key points (!732) In-Reply-To: References: Message-ID: @lumag should we include that or is there a better text to add? -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/732#note_100878987 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 12 17:11:27 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 12 Sep 2018 15:11:27 +0000 Subject: [gnutls-devel] GnuTLS | priority: be backwards compatible with priority strings starting with NONE (!738) In-Reply-To: References: Message-ID: Merged manually. -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/738#note_100879375 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 12 17:11:28 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 12 Sep 2018 15:11:28 +0000 Subject: [gnutls-devel] GnuTLS | priority: be backwards compatible with priority strings starting with NONE (!738) In-Reply-To: References: Message-ID: Merge Request !738 was closed by Nikos Mavrogiannopoulos Merge Request url: https://gitlab.com/gnutls/gnutls/merge_requests/738 Branches: tmp-be-backwards-compatible-with-prio to master Author: Nikos Mavrogiannopoulos Assignee: -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/738 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 12 17:11:22 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 12 Sep 2018 15:11:22 +0000 Subject: [gnutls-devel] GnuTLS | be backwards compatible with priority strings (#549) In-Reply-To: References: Message-ID: Issue was closed by Nikos Mavrogiannopoulos Issue #549: https://gitlab.com/gnutls/gnutls/issues/549 -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/549 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Wed Sep 12 17:11:44 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 12 Sep 2018 15:11:44 +0000 Subject: [gnutls-devel] GnuTLS | priority: be backwards compatible with priority strings starting with NONE (!738) In-Reply-To: References: Message-ID: Reassigned Merge Request 738 https://gitlab.com/gnutls/gnutls/merge_requests/738 Assignee changed to Nikos Mavrogiannopoulos -- Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/merge_requests/738 You're receiving this email because of your account on gitlab.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnutls-devel at lists.gnutls.org Thu Sep 13 00:44:45 2018 From: gnutls-devel at lists.gnutls.org (Development of GNU's TLS library) Date: Wed, 12 Sep 2018 22:44:45 +0000 Subject: [gnutls-devel] GnuTLS | p11tool --initialize-so-pin does not change so pin but initializes user pin (#561) References: Message-ID: New Issue was created. Issue 561: https://gitlab.com/gnutls/gnutls/issues/561 Author: Patrick Steuer Assignee: ## Description of problem: Hello gnutls team, I have some problems with p11tool's --initialize-so-pin and --initialize-pin options: I configured opencryptoki as pkcs11 provider using a p11-kit config file /etc/pkcs11/modules/opencryptoki.module. I initialized the token as follows: ``` p11tool --list-tokens Token 0: URL: pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=IBM%20OS%20PKCS%2311 Label: IBM OS PKCS#11 Type: Generic token Flags: RNG, Requires login, Uninitialized, uPIN uninitialized Manufacturer: IBM Corp. Model: IBM SoftTok Serial: 123 Module: /usr/local/lib/opencryptoki/libopencryptoki.so p11tool --initialize --label="swtok" pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=IBM%20OS%20PKCS%2311 Enter Security Officer's PIN: (INPUT: 87654321, "default so pin") Initializing token... done Token was successfully initialized; use --initialize-pin and --initialize-so-pin to set or reset PINs p11tool --list-tokens Token 0: URL: pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=swtok Label: swtok Type: Generic token Flags: RNG, Requires login, uPIN uninitialized Manufacturer: IBM Corp. Model: IBM SoftTok Serial: 123 Module: /usr/local/lib/opencryptoki/libopencryptoki.so ``` After initialization, the token has the default pin (87654321) and so the CKF_SO_PIN_TO_BE_CHANGED flag is set. The flag is not shown in the --list-tokens output, but when i activated p11-kit's log-calls (pkcs11.conf(5)), I could see it is actually set. Next i tried to change the so pin using --initialize-so-pin. When i set the default so pin using the environment variable (GNUTLS_SO_PIN=87654321), i could not even enter a new so pin, it just says "Setting token's user PIN...". The debug trace shows a successfull login using the default so pin and initializing the user pin (C_InitPIN) to the same value (87654321): ``` GNUTLS_SO_PIN=87654321 p11tool --initialize-so-pin pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=swtok C_Initialize IN: pInitArgs = NULL C_Initialize = CKR_OK C_GetInfo OUT: pInfo = { cryptokiVersion: 2.20 manufacturerID: "IBM" flags: 0 libraryDescription: "Meta PKCS11 LIBRARY" libraryVersion: 3.10 } C_GetInfo = CKR_OK Setting token's user PIN... C_GetSlotList IN: tokenPresent = CK_TRUE IN: pulCount = 0x3FFDD67DE28 = 48 OUT: pSlotList = (1) [ SL3 ] C_GetSlotList = CKR_OK C_GetTokenInfo IN: slotID = SL3 OUT: pInfo = { label: "swtok" manufacturerID: "IBM Corp." model: "IBM SoftTok" serialNumber: "123" flags: 8389709 = CKF_RNG | CKF_LOGIN_REQUIRED | CKF_USER_PIN_INITIALIZED | CKF_CLOCK_ON_TOKEN | CKF_TOKEN_INITIALIZED | CKF_SO_PIN_TO_BE_CHANGED ulMaxSessionCount: 18446744073709551614 ulSessionCount: 0 ulMaxRwSessionCount: 18446744073709551614 ulRwSessionCount: 18446744073709551615 ulMaxPinLen: 8 ulMinPinLen: 4 ulTotalPublicMemory: 18446744073709551614 ulFreePublicMemory: 18446744073709551614 ulTotalPrivateMemory: 18446744073709551614 ulFreePrivateMemory: 18446744073709551614 ulFreePrivateMemory: 18446744073709551614 hardwareVersion: 1.0 firmwareVersion: 1.0 utcTime: 2018091222592200 } C_GetTokenInfo = CKR_OK C_GetSlotInfo IN: slotID = SL3 OUT: pInfo = { slotDescription: "Linux" manufacturerID: "IBM" flags: 1 = CKF_TOKEN_PRESENT hardwareVersion: 0.0 firmwareVersion: 0.0 } C_GetSlotInfo = CKR_OK C_OpenSession:wa IN: slotID = SL3 IN: flags = 6 = CKF_SERIAL_SESSION | CKF_RW_SESSION IN: pApplication = NULL IN: Notify = NULL OUT: phSession = 0x3FFDD67E1D8 = S1 C_OpenSession = CKR_OK C_GetSessionInfo IN: hSession = S1 OUT: pInfo = { slotID: SL3 state: CKS_RW_PUBLIC_SESSION flags: 6 = CKF_SERIAL_SESSION | CKF_RW_SESSION ulDeviceError: 0 } C_GetSessionInfo = CKR_OK C_Login IN: hSession = S1 IN: userType = CKU_SO IN: pPin = (8) "87654321" C_Login = CKR_OK C_InitPIN IN: hSession = S1 IN: pPin = (8) "87654321" C_InitPIN = CKR_OK C_CloseSession IN: hSession = S1 C_CloseSession = CKR_OK C_Finalize IN: pReserved = NULL C_Finalize = CKR_OK ``` Next thing i tried is changing the so pin without having the environment variable set. In that case i was asked to enter a new so pin ("Enter Administrators's new PIN") and entered a pin different from the default so pin. However, the debug trace still shows a successful login using the default so pin and afterwards initializes the user pin to the same value: ``` p11tool --initialize-so-pin pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=swtok C_Initialize IN: pInitArgs = NULL C_Initialize = CKR_OK C_GetInfo OUT: pInfo = { cryptokiVersion: 2.20 manufacturerID: "IBM" flags: 0 libraryDescription: "Meta PKCS11 LIBRARY" libraryVersion: 3.10 } C_GetInfo = CKR_OK Setting token's user PIN... Enter Administrators's new PIN: (INPUT: 76543210, "new so pin") C_GetSlotList IN: tokenPresent = CK_TRUE IN: pulCount = 0x3FFEC77E0A8 = 48 OUT: pSlotList = (1) [ SL3 ] C_GetSlotList = CKR_OK C_GetTokenInfo IN: slotID = SL3 OUT: pInfo = { label: "swtok" manufacturerID: "IBM Corp." model: "IBM SoftTok" serialNumber: "123" flags: 8913989 = CKF_RNG | CKF_LOGIN_REQUIRED | CKF_CLOCK_ON_TOKEN | CKF_TOKEN_INITIALIZED | CKF_USER_PIN_TO_BE_CHANGED | CKF_SO_PIN_TO_BE_CHANGED ulMaxSessionCount: 18446744073709551614 ulSessionCount: 0 ulMaxRwSessionCount: 18446744073709551614 ulRwSessionCount: 18446744073709551615 ulMaxPinLen: 8 ulMinPinLen: 4 ulTotalPublicMemory: 18446744073709551614 ulFreePublicMemory: 18446744073709551614 ulTotalPrivateMemory: 18446744073709551614 ulFreePrivateMemory: 18446744073709551614 ulFreePrivateMemory: 18446744073709551614 hardwareVersion: 1.0 firmwareVersion: 1.0 utcTime: 2018091222532100 } C_GetTokenInfo = CKR_OK C_GetSlotInfo IN: slotID = SL3 OUT: pInfo = { slotDescription: "Linux" manufacturerID: "IBM" flags: 1 = CKF_TOKEN_PRESENT hardwareVersion: 0.0 firmwareVersion: 0.0 } C_GetSlotInfo = CKR_OK C_OpenSession IN: slotID = SL3 IN: flags = 6 = CKF_SERIAL_SESSION | CKF_RW_SESSION IN: pApplication = NULL IN: Notify = NULL OUT: phSession = 0x3FFEC77E458 = S1 C_OpenSession = CKR_OK C_GetSessionInfo IN: hSession = S1 OUT: pInfo = { slotID: SL3 state: CKS_RW_PUBLIC_SESSION flags: 6 = CKF_SERIAL_SESSION | CKF_RW_SESSION ulDeviceError: 0 } C_GetSessionInfo = CKR_OK Token 'swtok' with URL 'pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=swtok' requires security officer PIN Enter PIN: (INPUT: 87654321, "default so pin") C_Login IN: hSession = S1 IN: userType = CKU_SO IN: pPin = (8) "87654321" C_Login = CKR_OK C_InitPIN IN: hSession = S1 IN: pPin = (8) "87654321" C_InitPIN = CKR_OK C_CloseSession IN: hSession = S1 C_CloseSession = CKR_OK C_Finalize IN: pReserved = NULL C_Finalize = CKR_OK ``` In both cases (instead of changing the so pin) the user pin was initialized (to the default so pin): ``` p11tool --list-tokens Token 0: URL: pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=swtok Label: swtok Type: Generic token Flags: RNG, Requires login Manufacturer: IBM Corp. Model: IBM SoftTok Serial: 123 Module: /usr/local/lib/opencryptoki/libopencryptoki.so ``` pkcs11 v2.20 says regarding CKF_SO_PIN_TO_BE_CHANGED (which is set after the initialization): > [CKF_SO_PIN_TO_BE_CHANGED:] True if the SO PIN value is the default value set by token initialization or manufacturing, or the PIN has been expired by the card. > If a PIN is set to the default value, or has expired, the appropriate CKF_USER_PIN_TO_BE_CHANGED or CKF_SO_PIN_TO_BE_CHANGED flag is set to true. When either of these flags are true, logging in with the corresponding PIN will succeed, but only the C_SetPIN function can be called. Calling any other function that required the user to be logged in will cause CKR_PIN_EXPIRED to be returned until C_SetPIN is called successfully. pkcs11 v2.20 says regarding C_InitPin: > C_InitPIN initializes the normal user?s PIN. If the --initialize-so-pin option is meant to change the so pin, then it should do a C_Login with default so pin and a C_SetPIN using a new so pin instead of calling C_Login and C_InitPIN both with default so pin, as it is shown in the debug output above? Moreover, if the environment variable GNUTLS_SO_PIN is set, the pin for C_Login and C_InitPIN is read from it, so even if C_InitPIN could be used to change the so pin, it would always be set to the same default so pin. In case the environment variable is not set, both the new pin and the pin (for login) are read by the getpass function. However, it seems that function writes to a static buffer such that the second input (the default so pin for login) overwrites the first input, since it was not copied at the time it was obtained. So again, even if C_InitPin could be used to change the so pin, it would always be set to the same default so pin. If the --initialize-so-pin option is not meant to change the so pin, but instead just re-initialize it to its default value, why does it ask to enter a new admin pin (in case the environment variable is not set)? Which option should be used to change the so pin i.e., leave the CKF_SO_PIN_TO_BE_CHANGED state after initialization? Also, the static buffer problem described above, seems also to affect the --initialize-pin option: ``` p11tool --initialize-pin pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=swtok C_Initialize IN: pInitArgs = NULL C_Initialize = CKR_OK C_GetInfo OUT: pInfo = { cryptokiVersion: 2.20 manufacturerID: "IBM" flags: 0 libraryDescription: "Meta PKCS11 LIBRARY" libraryVersion: 3.10 } C_GetInfo = CKR_OK Setting token's user PIN... Enter User's new PIN: (INPUT: 76543210, "new user pin") C_GetSlotList IN: tokenPresent = CK_TRUE IN: pulCount = 0x3FFE2FFDC28 = 48 OUT: pSlotList = (1) [ SL3 ] C_GetSlotList = CKR_OK C_GetTokenInfo IN: slotID = SL3 OUT: pInfo = { label: "swtok" manufacturerID: "IBM Corp." model: "IBM SoftTok" serialNumber: "123" flags: 8913989 = CKF_RNG | CKF_LOGIN_REQUIRED | CKF_CLOCK_ON_TOKEN | CKF_TOKEN_INITIALIZED | CKF_USER_PIN_TO_BE_CHANGED | CKF_SO_PIN_TO_BE_CHANGED ulMaxSessionCount: 18446744073709551614 ulSessionCount: 0 ulMaxRwSessionCount: 18446744073709551614 ulRwSessionCount: 18446744073709551615 ulMaxPinLen: 8 ulMinPinLen: 4 ulTotalPublicMemory: 18446744073709551614 ulFreePublicMemory: 18446744073709551614 ulTotalPrivateMemory: 18446744073709551614 ulFreePrivateMemory: 18446744073709551614 ulFreePrivateMemory: 18446744073709551614 hardwareVersion: 1.0 firmwareVersion: 1.0 utcTime: 2018091223495800 } C_GetTokenInfo = CKR_OK C_GetSlotInfo IN: slotID = SL3 OUT: pInfo = { slotDescription: "Linux" manufacturerID: "IBM" flags: 1 = CKF_TOKEN_PRESENT hardwareVersion: 0.0 firmwareVersion: 0.0 } C_GetSlotInfo = CKR_OK C_OpenSession IN: slotID = SL3 IN: flags = 6 = CKF_SERIAL_SESSION | CKF_RW_SESSION IN: pApplication = NULL IN: Notify = NULL OUT: phSession = 0x3FFE2FFDFD8 = S1 C_OpenSession = CKR_OK C_GetSessionInfo IN: hSession = S1 OUT: pInfo = { slotID: SL3 state: CKS_RW_PUBLIC_SESSION flags: 6 = CKF_SERIAL_SESSION | CKF_RW_SESSION ulDeviceError: 0 } C_GetSessionInfo = CKR_OK Token 'swtok' with URL 'pkcs11:model=IBM%20SoftTok;manufacturer=IBM%20Corp.;serial=123;token=swtok' requires security officer PIN Enter PIN: (INPUT: 87654321, "default so pin") C_Login IN: hSession = S1 IN: userType = CKU_SO IN: pPin = (8) "87654321" C_Login = CKR_OK C_InitPIN IN: hSession = S1 IN: pPin = (8) "87654321" C_InitPIN = CKR_OK C_CloseSession IN: hSession = S1 C_CloseSession = CKR_OK C_Finalize IN: pReserved = NULL C_Finalize = CKR_OK ``` A work-around for the --initialize-pin option is to provide the default so pin via the corresponding environment variable. ## Version of gnutls used: gnutls-3.6.2-1.fc28.s390x gnutls-utils-3.6.2-1.fc28.s390x ## Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL) Fedora 28 (on s390x) ## How reproducible: 1. Set up opencryptoki as a pkcs11 provider using a p11-kit config file. 2. Initilize a token: p11tool --initialize --label="