From darrenm@sac.sfbay.sun.com Fri May 21 03:40:59 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LAexJm002758 for ; Fri, 21 May 2010 03:40:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LAevdr014326; Fri, 21 May 2010 05:40:59 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R00909N0AIO00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 21 May 2010 03:40:58 -0700 (PDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00K2NN09WI20@nwk-avmta-1.sfbay.Sun.COM>; Fri, 21 May 2010 03:40:57 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LAeusN007226; Fri, 21 May 2010 03:40:56 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LAesd2002752; Fri, 21 May 2010 03:40:54 -0700 (PDT) Received: (from darrenm@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o4LAesp9002748; Fri, 21 May 2010 03:40:54 -0700 (PDT) Date: Fri, 21 May 2010 03:40:54 -0700 (PDT) From: Darren J Moffat Subject: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] To: PSARC-ext@sun.com Cc: Jan.Pechanec@sun.com Message-id: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 6223 Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: PKCS#11 URI parser for libcryptoutil 1.2. Name of Document Author/Supplier: Author: Jan Pechanec 1.3 Date of This Document: 21 May, 2010 4. Technical Description Parsing the PKCS#11 URI in libcryptoutil ======================================== Overview -------- Applications start making use of the (not just HW) PKCS#11 keystores for storing private keys, and to a lesser extend also public keys and certificates. OpenSSL PKCS#11 Engine already allows applications to access PKCS#11 tokens that way (6479874) and there is also an ongoing project to add support for X.509 certificates into SunSSH (6357779) which also plans to use PKCS#11 keystores for storing private keys corresponding to certificates. Basically any application that uses private keys could benefit from having such keys in the PKCS#11 keystores. However, so far there is no unified way of referencing such keys/certs in the tokens. Recently we filed an Internet Draft "The PKCS#11 URI Scheme" specifying an URI that could help with referencing the PKCS#11 objects. The PKCS#11 URI was already used in the PKCS#11 Engine (PSARC/2009/555 OpenSSL RSA keys by reference in PKCS#11 keystores through the PKCS11 engine) and parsing code was included directly into the engine. We suggest to put the PKCS#11 URI parsing code into the libcryptoutil so that it's easily available to all consumers in ON. PKCS#11 URI Scheme ------------------ The PKCS#11 URI is fully described in the I-D which is located here: http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01 Extension to the existing libcryptoutil API ------------------------------------------- Given that libcryptoutil is consolidation private we can define a new structure in cryptoutil.h, visible in ON. We also use a few new defines. /* That's what getpassphrase(3c) supports. */ #define PK11_MAX_TOKEN_PIN_LEN 256 /* * There is no limit for the attribute length in the spec. 256 bytes * should be enough for the object name. */ #define PK11_MAX_OBJECT_LEN 256 /* * CKA_ID is of type "byte array" which can be of arbitrary length. 256 * bytes should be sufficient though. */ #define PK11_MAX_ID_LEN 256 #define PK11_MAX_PASSPHRASEDIALOG_LEN (MAXPATHLEN + sizeof ("exec:")) /* Structure for the PKCS#11 URI. */ typedef struct pkcs11_uri_t { CK_UTF8CHAR object[PK11_MAX_OBJECT_LEN + 1]; /* * The "objecttype" URI attribute can have a value of private, * public, cert, seckey, or data. The "objecttype" field can * have a value of CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, * CKO_CERTIFICATE, CKO_SECRET_KEY, or CKO_DATA. */ CK_ULONG objecttype; /* * CKO_DATA is 0 so we need this flag. Not part of the URI * itself. */ boolean_t objecttype_present; /* * Token, manuf, serial and model are of fixed size lengths as * defined in the specification. The +1s are for the terminating * '\0's which are not used in the CK_TOKEN_INFO structure * (fields are padded with spaces). */ /* Token label from CK_TOKEN_INFO. */ CK_UTF8CHAR token[32 + 1]; /* ManufacturerID from CK_TOKEN_INFO. */ CK_UTF8CHAR manuf[32 + 1]; /* SerialNumber from CK_TOKEN_INFO. */ CK_CHAR serial[16 + 1]; /* Model from CK_TOKEN_INFO. */ CK_UTF8CHAR model[16 + 1]; /* This is a byte array, we need a length parameter as well. */ CK_BYTE id[PK11_MAX_ID_LEN]; int id_len; /* Passphrase dialog for getting the token PIN. */ char passphrasedialog[PK11_MAX_PASSPHRASEDIALOG_LEN + 1]; /* * The token PIN. Not part of the URI itself. Will be filled * when the passphrasedialog attribute is used. +1 is for the * terminating '\0'. */ CK_UTF8CHAR pin[PK11_MAX_TOKEN_PIN_LEN + 1]; } pkcs11_uri_t; We need only one function for parsing the URI, all other helper functions are static. The function takes a string with the PKCS#11 URI and fills up a structure allocated by the caller. int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri); Return codes are defined: #define PK11_URI_OK 0 #define PK11_URI_INVALID 1 - the string begins with the "pkcs11://" prefix but the URI is otherwise invalid. It contains an unknown attribute, for example. #define PK11_TOKEN_PIN_NOT_READ 2 - there might be different reasons why the PIN has not been read. For example, the external passphrase-like command does not exist. #define PK11_MALLOC_ERROR 3 - internal malloc() has failed #define PK11_URI_VALUE_OVERFLOW 4 - the PKCS#11 spec defines some limits on attributes. #define PK11_NOT_PKCS11_URI 5 - the string does not begin with the "pkcs11://" prefix at all #define PK11_MUTEX_ERROR 6 - getpassphrase() is not MT-safe. We use a global mutex to protect the getpassphrase() call. Relevant CRs ------------ 6924687 teach libcryptoutil to parse a PKCS#11 URI 6953869 crypto framework STC-2 test suite needs a test for the PKCS#11 URI parsing Doc impact ---------- We will update the README file in usr/src/lib/libcryptoutil. Since libcryptoutil is private interface within ON it does not have its own manual page. Notes ----- We asked for feedback on the following aliases: saag@ietf.org - IETF Security Area Advisory Group cryptoki@rsasecurity.com - PKCS#11 alias at RSA Security (PKCS#11 came from there) opensc-devel@lists.opensc-project.org - open smart card project Unfortunately, we haven't received any feedback. However, given that libcryptoutil is consolidation private we believe we can implement the current specification and make changes in the future should those be needed. Interface Stability ------------------- Private. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gww@sac.sfbay.sun.com Fri May 21 07:58:17 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LEwHPx006765 for ; Fri, 21 May 2010 07:58:17 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4LEwHo5010873 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 21 May 2010 08:58:17 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2R0041RYX5H100@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 07:58:17 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2R00KX9YX4WRE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 21 May 2010 07:58:16 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LEwEjA002412; Fri, 21 May 2010 07:58:14 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LEwEYp006763; Fri, 21 May 2010 07:58:14 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id o4LEwEph006762; Fri, 21 May 2010 07:58:14 -0700 (PDT) Date: Fri, 21 May 2010 07:58:14 -0700 (PDT) From: Gary Winiger Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] To: PSARC-ext@sun.com, darrenm@sac.sfbay.sun.com Cc: Jan.Pechanec@sun.com Message-id: <201005211458.o4LEwEph006762@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 409 > We need only one function for parsing the URI, all other helper > functions are static. The function takes a string with the PKCS#11 URI > and fills up a structure allocated by the caller. > > int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri); > Interface Stability > ------------------- > > Private. As a Private interface until there's a reason to change, seems straight forward. +1 Gary.. From garrett.damore@oracle.com Fri May 21 09:18:26 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4LGIQ50007780 for ; Fri, 21 May 2010 09:18:26 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4LGIMjW027735; Fri, 21 May 2010 09:18:24 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2S0050L2MO1X00@brm-avmta-1.central.sun.com>; Fri, 21 May 2010 10:18:24 -0600 (MDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2S00KFF2MN5P60@brm-avmta-1.central.sun.com>; Fri, 21 May 2010 10:18:23 -0600 (MDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4LGIM8J000742; Fri, 21 May 2010 16:18:22 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4LGG1ol003846; Fri, 21 May 2010 16:18:21 +0000 (GMT) Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 288433691274458597; Fri, 21 May 2010 09:16:37 -0700 Received: from localhost (/97.207.252.36) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 21 May 2010 09:16:35 -0700 Date: Fri, 21 May 2010 09:16:46 -0700 From: "Garrett D'Amore" Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] To: Darren J Moffat , PSARC-ext@sun.com Cc: Jan.Pechanec@sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4BF6B24D.017C:SCFMA4539814,ss=1,fgs=0 Status: RO Content-Length: 6478 +1 -- Garrett Darren J Moffat wrote: > >Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. >1. Introduction > 1.1. Project/Component Working Name: > PKCS#11 URI parser for libcryptoutil > 1.2. Name of Document Author/Supplier: > Author: Jan Pechanec > 1.3 Date of This Document: > 21 May, 2010 >4. Technical Description >Parsing the PKCS#11 URI in libcryptoutil >======================================== > >Overview >-------- > >Applications start making use of the (not just HW) PKCS#11 keystores for >storing private keys, and to a lesser extend also public keys and >certificates. OpenSSL PKCS#11 Engine already allows applications to >access PKCS#11 tokens that way (6479874) and there is also an ongoing >project to add support for X.509 certificates into SunSSH (6357779) >which also plans to use PKCS#11 keystores for storing private keys >corresponding to certificates. Basically any application that uses >private keys could benefit from having such keys in the PKCS#11 >keystores. > >However, so far there is no unified way of referencing such keys/certs >in the tokens. Recently we filed an Internet Draft "The PKCS#11 URI >Scheme" specifying an URI that could help with referencing the PKCS#11 >objects. The PKCS#11 URI was already used in the PKCS#11 Engine >(PSARC/2009/555 OpenSSL RSA keys by reference in PKCS#11 keystores >through the PKCS11 engine) and parsing code was included directly into >the engine. > >We suggest to put the PKCS#11 URI parsing code into the libcryptoutil so >that it's easily available to all consumers in ON. > > >PKCS#11 URI Scheme >------------------ > >The PKCS#11 URI is fully described in the I-D which is located here: > > http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01 > > >Extension to the existing libcryptoutil API >------------------------------------------- > >Given that libcryptoutil is consolidation private we can define a new >structure in cryptoutil.h, visible in ON. We also use a few new defines. > > >/* That's what getpassphrase(3c) supports. */ >#define PK11_MAX_TOKEN_PIN_LEN 256 >/* > * There is no limit for the attribute length in the spec. 256 bytes > * should be enough for the object name. > */ >#define PK11_MAX_OBJECT_LEN 256 >/* > * CKA_ID is of type "byte array" which can be of arbitrary length. 256 > * bytes should be sufficient though. > */ >#define PK11_MAX_ID_LEN 256 >#define PK11_MAX_PASSPHRASEDIALOG_LEN (MAXPATHLEN + sizeof ("exec:")) > >/* Structure for the PKCS#11 URI. */ >typedef struct pkcs11_uri_t { > CK_UTF8CHAR object[PK11_MAX_OBJECT_LEN + 1]; > /* > * The "objecttype" URI attribute can have a value of private, > * public, cert, seckey, or data. The "objecttype" field can > * have a value of CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, > * CKO_CERTIFICATE, CKO_SECRET_KEY, or CKO_DATA. > */ > CK_ULONG objecttype; > /* > * CKO_DATA is 0 so we need this flag. Not part of the URI > * itself. > */ > boolean_t objecttype_present; > /* > * Token, manuf, serial and model are of fixed size lengths as > * defined in the specification. The +1s are for the terminating > * '\0's which are not used in the CK_TOKEN_INFO structure > * (fields are padded with spaces). > */ > /* Token label from CK_TOKEN_INFO. */ > CK_UTF8CHAR token[32 + 1]; > /* ManufacturerID from CK_TOKEN_INFO. */ > CK_UTF8CHAR manuf[32 + 1]; > /* SerialNumber from CK_TOKEN_INFO. */ > CK_CHAR serial[16 + 1]; > /* Model from CK_TOKEN_INFO. */ > CK_UTF8CHAR model[16 + 1]; > /* This is a byte array, we need a length parameter as well. */ > CK_BYTE id[PK11_MAX_ID_LEN]; > int id_len; > /* Passphrase dialog for getting the token PIN. */ > char passphrasedialog[PK11_MAX_PASSPHRASEDIALOG_LEN + 1]; > /* > * The token PIN. Not part of the URI itself. Will be filled > * when the passphrasedialog attribute is used. +1 is for the > * terminating '\0'. > */ > CK_UTF8CHAR pin[PK11_MAX_TOKEN_PIN_LEN + 1]; >} pkcs11_uri_t; > > >We need only one function for parsing the URI, all other helper >functions are static. The function takes a string with the PKCS#11 URI >and fills up a structure allocated by the caller. > > int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri); > >Return codes are defined: > >#define PK11_URI_OK 0 >#define PK11_URI_INVALID 1 > - the string begins with the "pkcs11://" prefix but the URI is > otherwise invalid. It contains an unknown attribute, for > example. >#define PK11_TOKEN_PIN_NOT_READ 2 > - there might be different reasons why the PIN has not been > read. For example, the external passphrase-like command does > not exist. >#define PK11_MALLOC_ERROR 3 > - internal malloc() has failed >#define PK11_URI_VALUE_OVERFLOW 4 > - the PKCS#11 spec defines some limits on attributes. >#define PK11_NOT_PKCS11_URI 5 > - the string does not begin with the "pkcs11://" prefix at all >#define PK11_MUTEX_ERROR 6 > - getpassphrase() is not MT-safe. We use a global mutex to > protect the getpassphrase() call. > >Relevant CRs >------------ > >6924687 teach libcryptoutil to parse a PKCS#11 URI >6953869 crypto framework STC-2 test suite needs a test for the PKCS#11 > URI parsing > >Doc impact >---------- > >We will update the README file in usr/src/lib/libcryptoutil. Since >libcryptoutil is private interface within ON it does not have its own >manual page. > >Notes >----- > >We asked for feedback on the following aliases: > > saag@ietf.org > - IETF Security Area Advisory Group > > cryptoki@rsasecurity.com > - PKCS#11 alias at RSA Security (PKCS#11 came from > there) > > opensc-devel@lists.opensc-project.org > - open smart card project > >Unfortunately, we haven't received any feedback. However, given that >libcryptoutil is consolidation private we believe we can implement the >current specification and make changes in the future should those be >needed. > >Interface Stability >------------------- > >Private. > > >6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > ON > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > From Jan.Pechanec@sun.com Mon May 24 05:08:36 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4OC8aZq028841 for ; Mon, 24 May 2010 05:08:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4OC8ZBP023739 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Mon, 24 May 2010 05:08:35 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2X00507B2B1H00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 24 May 2010 06:08:35 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2X004ZNB2AWBA0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Mon, 24 May 2010 06:08:35 -0600 (MDT) Received: from fe-emea-13.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4OC8XXe021750 for ; Mon, 24 May 2010 12:08:34 +0000 (GMT) Received: from conversion-daemon.fe-emea-13.sun.com by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L2X00G00AZH9R00@fe-emea-13.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Mon, 24 May 2010 13:08:17 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-13.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L2X00G8IB1S6U30@fe-emea-13.sun.com>; Mon, 24 May 2010 13:08:17 +0100 (BST) Date: Mon, 24 May 2010 14:07:58 +0200 (CEST) From: Jan Pechanec Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] In-reply-to: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> Sender: Jan.Pechanec@sun.com X-X-Sender: jp161948@rejewski To: Darren J Moffat Cc: PSARC-ext@sun.com, gww@sac.sfbay.sun.com, garrett.damore@oracle.com Message-id: Content-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_d8C8Vm4Cz+8EfdqxbouVMQ)" X-PMX-Version: 5.4.1.325704 References: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> Status: RO Content-Length: 8437 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_d8C8Vm4Cz+8EfdqxbouVMQ) Content-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Fri, 21 May 2010, Darren J Moffat wrote: >Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. >1. Introduction > 1.1. Project/Component Working Name: > PKCS#11 URI parser for libcryptoutil > 1.2. Name of Document Author/Supplier: > Author: Jan Pechanec > 1.3 Date of This Document: > 21 May, 2010 >4. Technical Description >Parsing the PKCS#11 URI in libcryptoutil >======================================== when writing a new STC-2 test case for this I realized that having fixed arrays for strings in the PKCS#11 URI structure imposes an unneccessary limitation that we could not differentiate an empty attribute value from an attribute not specified at all: pkcs11: pkcs11:serial= the I-D allows empty values (logically) so I slightly changed the specification so the pkcs11_uri_t structure contains pointers to strings now. Strings are being allocated on the fly. If the pointer is NULL, the attribute was not specified, and "" string is a valid value. given that we need one new function: void pkcs11_free_uri(pkcs11_uri_t *uri); that frees all allocated strings so that the programmer does not have to do that manually. The pkcs11_uri_t structure itself is not freed. cc'ing Gary and Garrett who gave their +1s to the initial spec. The new one is attached. thanks, Jan. -- Jan Pechanec http://blogs.sun.com/janp --Boundary_(ID_d8C8Vm4Cz+8EfdqxbouVMQ) Content-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=pkcs11uri-psarc.txt Content-transfer-encoding: 7BIT Content-disposition: ATTACHMENT; FILENAME=pkcs11uri-psarc.txt Content-description: Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: PKCS#11 URI parser for libcryptoutil 1.2. Name of Document Author/Supplier: Author: Jan Pechanec 1.3 Date of This Document: 21 May, 2010 4. Technical Description Parsing the PKCS#11 URI in libcryptoutil ======================================== Overview -------- Applications start making use of the (not just HW) PKCS#11 keystores for storing private keys, and to a lesser extend also public keys and certificates. OpenSSL PKCS#11 Engine already allows applications to access PKCS#11 tokens that way (6479874) and there is also an ongoing project to add support for X.509 certificates into SunSSH (6357779) which also plans to use PKCS#11 keystores for storing private keys corresponding to certificates. Basically any application that uses private keys could benefit from having such keys in the PKCS#11 keystores. However, so far there is no unified way of referencing such keys/certs in the tokens. Recently we filed an Internet Draft "The PKCS#11 URI Scheme" specifying an URI that could help with referencing the PKCS#11 objects. The PKCS#11 URI was already used in the PKCS#11 Engine (PSARC/2009/555 OpenSSL RSA keys by reference in PKCS#11 keystores through the PKCS11 engine) and parsing code was included directly into the engine. We suggest to put the PKCS#11 URI parsing code into the libcryptoutil so that it's easily available to all consumers in ON. PKCS#11 URI Scheme ------------------ The PKCS#11 URI is fully described in the I-D which is located here: http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01 Extension to the existing libcryptoutil API ------------------------------------------- Given that libcryptoutil is consolidation private we can define a new structure in cryptoutil.h, visible in ON. We also use a few new defines. /* That's what getpassphrase(3c) supports. */ #define PK11_MAX_TOKEN_PIN_LEN 256 /* * There is no limit for the attribute length in the spec. 256 bytes * should be enough for the object name. */ #define PK11_MAX_OBJECT_LEN 256 /* * CKA_ID is of type "byte array" which can be of arbitrary length. 256 * bytes should be sufficient though. */ #define PK11_MAX_ID_LEN 256 #define PK11_MAX_PASSPHRASEDIALOG_LEN (MAXPATHLEN + sizeof ("exec:")) /* Structure for the PKCS#11 URI. */ /* Structure for the PKCS#11 URI. */ typedef struct pkcs11_uri_t { CK_UTF8CHAR_PTR object; /* * The "objecttype" URI attribute can have a value of private, * public, cert, seckey, or data. The "objecttype" field can * have a value of CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, * CKO_CERTIFICATE, CKO_SECRET_KEY, or CKO_DATA. */ CK_ULONG objecttype; /* * CKO_DATA is 0 so we need this flag. Not part of the URI * itself. */ boolean_t objecttype_present; /* * Token, manuf, serial and model are of fixed size lengths as * defined in the specification. The +1s are for the terminating * '\0's which are not used in the CK_TOKEN_INFO structure * (fields are padded with spaces). */ /* Token label from CK_TOKEN_INFO. */ CK_UTF8CHAR_PTR token; /* ManufacturerID from CK_TOKEN_INFO. */ CK_UTF8CHAR_PTR manuf; /* SerialNumber from CK_TOKEN_INFO. */ CK_CHAR_PTR serial; /* Model from CK_TOKEN_INFO. */ CK_UTF8CHAR_PTR model; /* This is a byte array, we need a length parameter as well. */ CK_BYTE_PTR id; int id_len; /* Passphrase dialog for getting the token PIN. */ char *passphrasedialog; /* * The token PIN. Not part of the URI itself. Will be filled * when the passphrasedialog attribute is used. +1 is for the * terminating '\0'. */ CK_UTF8CHAR_PTR pin; } pkcs11_uri_t; We need only one function for parsing the URI, and one function to free the URI structure. All other functions are both auxiliary and static. The pkcs11_parse_uri() function takes a string with the PKCS#11 URI and fills up a structure allocated by the caller. pkcs11_free_uri() frees allocated fields but does not attempt to free the structure itself. int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri); void pkcs11_free_uri(pkcs11_uri_t *uri); Return codes are defined: #define PK11_URI_OK 0 #define PK11_URI_INVALID 1 - the string begins with the "pkcs11://" prefix but the URI is otherwise invalid. It contains an unknown attribute, for example. #define PK11_TOKEN_PIN_NOT_READ 2 - there might be different reasons why the PIN has not been read. For example, the external passphrase-like command does not exist. #define PK11_MALLOC_ERROR 3 - internal malloc() has failed #define PK11_URI_VALUE_OVERFLOW 4 - the PKCS#11 spec defines some limits on attributes. #define PK11_NOT_PKCS11_URI 5 - the string does not begin with the "pkcs11://" prefix at all #define PK11_MUTEX_ERROR 6 - getpassphrase() is not MT-safe. We use a global mutex to protect the getpassphrase() call. Relevant CRs ------------ 6924687 teach libcryptoutil to parse a PKCS#11 URI 6953869 crypto framework STC-2 test suite needs a test for the PKCS#11 URI parsing Doc impact ---------- We will update the README file in usr/src/lib/libcryptoutil. Since libcryptoutil is private interface within ON it does not have its own manual page. Notes ----- We asked for feedback on the following aliases: saag@ietf.org - IETF Security Area Advisory Group cryptoki@rsasecurity.com - PKCS#11 alias at RSA Security (PKCS#11 came from there) opensc-devel@lists.opensc-project.org - open smart card project Unfortunately, we haven't received any feedback. However, given that libcryptoutil is consolidation private we believe we can implement the current specification and make changes in the future should those be needed. Interface Stability ------------------- Private. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open --Boundary_(ID_d8C8Vm4Cz+8EfdqxbouVMQ)-- From Nicolas.Williams@oracle.com Tue May 25 13:33:54 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4PKXshi022073 for ; Tue, 25 May 2010 13:33:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4PKXqZO020859; Tue, 25 May 2010 14:33:53 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Z0080DT4GWP00@nwk-avmta-2.sfbay.sun.com>; Tue, 25 May 2010 13:33:52 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Z005YST4GFZ90@nwk-avmta-2.sfbay.sun.com>; Tue, 25 May 2010 13:33:52 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4PKXpOe029912; Tue, 25 May 2010 20:33:51 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PETVW6024025; Tue, 25 May 2010 20:33:50 +0000 (GMT) Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 267457441274819627; Tue, 25 May 2010 13:33:47 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 13:33:47 -0700 Date: Tue, 25 May 2010 15:33:42 -0500 From: Nicolas Williams Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] In-reply-to: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> To: Darren J Moffat Cc: PSARC-ext@sun.com, Jan.Pechanec@sun.com Message-id: <20100525203342.GI9605@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BFC342F.0089:SCFMA4539814,ss=1,fgs=0 References: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 773 On Fri, May 21, 2010 at 03:40:54AM -0700, Darren J Moffat wrote: > /* That's what getpassphrase(3c) supports. */ > #define PK11_MAX_TOKEN_PIN_LEN 256 ... > int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri); > > Return codes are defined: ... > #define PK11_MUTEX_ERROR 6 > - getpassphrase() is not MT-safe. We use a global mutex to > protect the getpassphrase() call. Hmmm, I think it'd have been better to have the function return an error when a PIN is need and let the app call it again with the PIN -- let the app prompt for a PIN. There's no way to deal with the fact that getpassphrase() is not MT-safe from within a library. The mutex you use to synchronize access to it will not be the same mutex that the application uses. Nico -- From carlsonj@workingcode.com Tue May 25 14:01:33 2010 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4PL1Wu1023084 for ; Tue, 25 May 2010 14:01:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.4) with ESMTP id o4PL1VWw034039; Tue, 25 May 2010 15:01:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Z00605UEJKP00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 25 May 2010 14:01:31 -0700 (PDT) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Z003VIUEILJB0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 25 May 2010 14:01:30 -0700 (PDT) Received: from relay14i.sun.com (ip124.net129179-4.block1.us.syntegra.com [129.179.4.124]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4PKn9bE009095; Tue, 25 May 2010 21:01:29 +0000 (GMT) Received: from mmp13es.mmp.us.syntegra.com ([160.41.208.13] [160.41.208.13]) by relay14i.sun.com with ESMTP id BT-MMP-4018220; Tue, 25 May 2010 21:00:57 +0000 (Z) Received: from relay14i.sun.com (relay14i.sun.com [129.179.4.124]) by mmp13es.mmp.us.syntegra.com with ESMTP id BT-MMP-230354176; Tue, 25 May 2010 21:00:57 +0000 (Z) Received: from carlson.workingcode.com ([75.150.68.97] [75.150.68.97]) by relay1i.sun.com with ESMTP id BT-MMP-1957320; Tue, 25 May 2010 21:00:56 +0000 (Z) Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id o4PL0o5f003578 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 May 2010 17:00:50 -0400 (EDT) Date: Tue, 25 May 2010 17:00:50 -0400 From: James Carlson Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] In-reply-to: <20100525203342.GI9605@oracle.com> To: Nicolas Williams Cc: Darren J Moffat , PSARC-ext@sun.com, Jan.Pechanec@sun.com Message-id: <4BFC3A82.1050008@workingcode.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Brightmail-Tracker: AAAAAA== X-DCC-URT-Metrics: carlson; whitelist X-Antispam: No, score=0.0/5.0, scanned in 0.228sec at (localhost [127.0.0.1]) by smf-spamd v1.3.1 - http://smfs.sf.net/ References: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> <20100525203342.GI9605@oracle.com> User-Agent: Thunderbird 2.0.0.22 (X11/20090605) Status: RO Content-Length: 1101 Nicolas Williams wrote: > On Fri, May 21, 2010 at 03:40:54AM -0700, Darren J Moffat wrote: >> /* That's what getpassphrase(3c) supports. */ >> #define PK11_MAX_TOKEN_PIN_LEN 256 > ... >> int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri); >> >> Return codes are defined: > ... >> #define PK11_MUTEX_ERROR 6 >> - getpassphrase() is not MT-safe. We use a global mutex to >> protect the getpassphrase() call. > > Hmmm, I think it'd have been better to have the function return an error > when a PIN is need and let the app call it again with the PIN -- let the > app prompt for a PIN. > > There's no way to deal with the fact that getpassphrase() is not > MT-safe from within a library. The mutex you use to synchronize access > to it will not be the same mutex that the application uses. Perhaps more important for a library function: there's no way to know exactly how one gets input from a user. It might involve interactions with a GUI or through some other sort of protocol (such as EAP). -- James Carlson 42.703N 71.076W From Nicolas.Williams@oracle.com Tue May 25 14:07:19 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4PL7J9d023157 for ; Tue, 25 May 2010 14:07:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4PL7E0e025670; Tue, 25 May 2010 14:07:17 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L2Z00809UO40N00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 25 May 2010 14:07:16 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L2Z0031WUO3LIC0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 25 May 2010 14:07:15 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o4PL7ERl016945; Tue, 25 May 2010 21:07:14 +0000 (GMT) Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o4PHxSAq030371; Tue, 25 May 2010 21:07:09 +0000 (GMT) Received: from abhmt004.oracle.com by acsmt355.oracle.com with ESMTP id 267553261274821576; Tue, 25 May 2010 14:06:16 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 May 2010 14:06:16 -0700 Date: Tue, 25 May 2010 16:06:11 -0500 From: Nicolas Williams Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] In-reply-to: <4BFC3A82.1050008@workingcode.com> To: James Carlson Cc: Darren J Moffat , PSARC-ext@sun.com, Jan.Pechanec@sun.com Message-id: <20100525210611.GK9605@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4BFC3BFE.0135:SCFMA4539814,ss=1,fgs=0 References: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> <20100525203342.GI9605@oracle.com> <4BFC3A82.1050008@workingcode.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 1090 On Tue, May 25, 2010 at 05:00:50PM -0400, James Carlson wrote: > Nicolas Williams wrote: > > Hmmm, I think it'd have been better to have the function return an error > > when a PIN is need and let the app call it again with the PIN -- let the > > app prompt for a PIN. > > > > There's no way to deal with the fact that getpassphrase() is not > > MT-safe from within a library. The mutex you use to synchronize access > > to it will not be the same mutex that the application uses. > > Perhaps more important for a library function: there's no way to know > exactly how one gets input from a user. It might involve interactions > with a GUI or through some other sort of protocol (such as EAP). Looking at the webrev I see a way to invoke an external command to produce the PIN. But even with that a GUI app would have to have an external command to do something that could be done without having to invoke an external command if only this API didn't require the ability to prompt for a PIN by itself. I recommend a callback and/or a PIN argument and pin-needed error code. Nico -- From Jan.Pechanec@Sun.COM Wed May 26 04:41:36 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o4QBfam2027341 for ; Wed, 26 May 2010 04:41:36 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o4QBfYkD029567 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 26 May 2010 04:41:35 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L300070JZ5BSS00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 26 May 2010 05:41:35 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L30003ACZ594050@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 26 May 2010 05:41:34 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o4QBfVBV009754 for ; Wed, 26 May 2010 11:41:32 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L3000K00XXPPE00@fe-emea-10.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 26 May 2010 12:41:30 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L3000GKSZ52W5E0@fe-emea-10.sun.com>; Wed, 26 May 2010 12:41:26 +0100 (BST) Date: Wed, 26 May 2010 13:41:07 +0200 (CEST) From: Jan Pechanec Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] In-reply-to: <4BFC3A82.1050008@workingcode.com> Sender: Jan.Pechanec@Sun.COM X-X-Sender: jp161948@rejewski To: James Carlson Cc: Nicolas Williams , Darren J Moffat , PSARC-ext@Sun.COM Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> <20100525203342.GI9605@oracle.com> <4BFC3A82.1050008@workingcode.com> Status: RO Content-Length: 1434 On Tue, 25 May 2010, James Carlson wrote: >Nicolas Williams wrote: >> On Fri, May 21, 2010 at 03:40:54AM -0700, Darren J Moffat wrote: >>> /* That's what getpassphrase(3c) supports. */ >>> #define PK11_MAX_TOKEN_PIN_LEN 256 >> ... >>> int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri); >>> >>> Return codes are defined: >> ... >>> #define PK11_MUTEX_ERROR 6 >>> - getpassphrase() is not MT-safe. We use a global mutex to >>> protect the getpassphrase() call. >> >> Hmmm, I think it'd have been better to have the function return an error >> when a PIN is need and let the app call it again with the PIN -- let the >> app prompt for a PIN. >> >> There's no way to deal with the fact that getpassphrase() is not >> MT-safe from within a library. The mutex you use to synchronize access >> to it will not be the same mutex that the application uses. > >Perhaps more important for a library function: there's no way to know >exactly how one gets input from a user. It might involve interactions >with a GUI or through some other sort of protocol (such as EAP). there are two options in the original spec: passphrasedialog=builtin passphrasedialog=exec:program the 2nd one is quite generic, one can write a script that can do anything. Anyway, I agree now that libcryptoutil should not ask via getpassphrase(), I'm now working on a changed design. J. -- Jan Pechanec http://blogs.sun.com/janp From Jan.Pechanec@sun.com Wed Jun 2 07:44:52 2010 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o52EiqeY001240 for ; Wed, 2 Jun 2010 07:44:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o52EiqPm019309 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 07:44:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3E00D076ASK900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Jun 2010 07:44:52 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E000LA6AQGHE0@nwk-avmta-1.sfbay.Sun.COM> for PSARC-ext@sun.com (ORCPT PSARC-ext@Sun.COM); Wed, 02 Jun 2010 07:44:50 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o52EintN005431 for ; Wed, 02 Jun 2010 14:44:49 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L3E0050060EH500@fe-emea-09.sun.com> for PSARC-ext@Sun.COM (ORCPT PSARC-ext@Sun.COM); Wed, 02 Jun 2010 15:44:34 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L3E008XI6A9BP00@fe-emea-09.sun.com>; Wed, 02 Jun 2010 15:44:33 +0100 (BST) Date: Wed, 02 Jun 2010 16:44:11 +0200 (CEST) From: Jan Pechanec Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] In-reply-to: Sender: Jan.Pechanec@sun.com X-X-Sender: jp161948@rejewski To: Darren J Moffat Cc: PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_EMTnk52n3LP9wsT+FaqKfw)" X-PMX-Version: 5.4.1.325704 References: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> Status: RO Content-Length: 7917 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --Boundary_(ID_EMTnk52n3LP9wsT+FaqKfw) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT On Mon, 24 May 2010, Jan Pechanec wrote: >>Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI >>This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. >>1. Introduction >> 1.1. Project/Component Working Name: >> PKCS#11 URI parser for libcryptoutil >> 1.2. Name of Document Author/Supplier: >> Author: Jan Pechanec >> 1.3 Date of This Document: >> 21 May, 2010 >>4. Technical Description >>Parsing the PKCS#11 URI in libcryptoutil >>======================================== > > when writing a new STC-2 test case for this I realized that >having fixed arrays for strings in the PKCS#11 URI structure imposes an >unneccessary limitation that we could not differentiate an empty >attribute value from an attribute not specified at all: one last change, hopefully. The "passphrasedialog" changed to the "pinfile". This resulted from the codereview done on the ef-interest@sun.com. Depending on the application, the value could be overloaded to contain "/bin/askpass|", for example, to suggest that the PIN should be read from the external command. updated spec attached. thanks, J. -- Jan Pechanec http://blogs.sun.com/janp --Boundary_(ID_EMTnk52n3LP9wsT+FaqKfw) Content-id: Content-type: TEXT/PLAIN; CHARSET=US-ASCII; name=pkcs11uri-psarc.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=pkcs11uri-psarc.txt Content-description: Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI This information is Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved. 1. Introduction 1.1. Project/Component Working Name: PKCS#11 URI parser for libcryptoutil 1.2. Name of Document Author/Supplier: Author: Jan Pechanec 1.3 Date of This Document: 21 May, 2010 4. Technical Description Parsing the PKCS#11 URI in libcryptoutil ======================================== Overview -------- Applications start making use of the (not just HW) PKCS#11 keystores for storing private keys, and to a lesser extend also public keys and certificates. OpenSSL PKCS#11 Engine already allows applications to access PKCS#11 tokens that way (6479874) and there is also an ongoing project to add support for X.509 certificates into SunSSH (6357779) which also plans to use PKCS#11 keystores for storing private keys corresponding to certificates. Basically any application that uses private keys could benefit from having such keys in the PKCS#11 keystores. However, so far there is no unified way of referencing such keys/certs in the tokens. Recently we filed an Internet Draft "The PKCS#11 URI Scheme" specifying an URI that could help with referencing the PKCS#11 objects. The PKCS#11 URI was already used in the PKCS#11 Engine (PSARC/2009/555 OpenSSL RSA keys by reference in PKCS#11 keystores through the PKCS11 engine) and parsing code was included directly into the engine. We suggest to put the PKCS#11 URI parsing code into the libcryptoutil so that it's easily available to all consumers in ON. PKCS#11 URI Scheme ------------------ The PKCS#11 URI is described in the I-D which is located here: http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01 There will be one change. During the codereview done on the internal ef-interest@ aliais it was agreed on that instead of the "passhphrasedialog" attribute we should use the "pinfile" attribute. The value will hold a filename containing the token PIN. Applications may overload this to accept "prog_name|" to read the PIN from a external program. However, the pkcs11_parse_uri() will never run any external program to read the PIN nor it will interpret the "pinfile" attribute value in any way. The I-D will be updated. Extension to the existing libcryptoutil API ------------------------------------------- Given that libcryptoutil is consolidation private we can define a new structure in cryptoutil.h, visible in ON. We also use a few new defines. /* * There is no limit for the attribute length in the spec. 256 bytes * should be enough for the object name. */ #define PK11_MAX_OBJECT_LEN 256 /* * CKA_ID is of type "byte array" which can be of arbitrary length. 256 * bytes should be sufficient though. */ #define PK11_MAX_ID_LEN 256 /* Structure for the PKCS#11 URI. */ typedef struct pkcs11_uri_t { CK_UTF8CHAR_PTR object; /* * The "objecttype" URI attribute can have a value of private, * public, cert, seckey, or data. The "objecttype" field can * have a value of CKO_PUBLIC_KEY, CKO_PRIVATE_KEY, * CKO_CERTIFICATE, CKO_SECRET_KEY, or CKO_DATA. */ CK_ULONG objecttype; /* * CKO_DATA is 0 so we need this flag. Not part of the URI * itself. */ boolean_t objecttype_present; /* * Token, manuf, serial and model are of fixed size lengths as * defined in the specification. The +1s are for the terminating * '\0's which are not used in the CK_TOKEN_INFO structure * (fields are padded with spaces). */ /* Token label from CK_TOKEN_INFO. */ CK_UTF8CHAR_PTR token; /* ManufacturerID from CK_TOKEN_INFO. */ CK_UTF8CHAR_PTR manuf; /* SerialNumber from CK_TOKEN_INFO. */ CK_CHAR_PTR serial; /* Model from CK_TOKEN_INFO. */ CK_UTF8CHAR_PTR model; /* This is a byte array, we need a length parameter as well. */ CK_BYTE_PTR id; int id_len; /* * Location of the file with a token PIN. Application can * overload this, eg. "/bin/askpass|" may mean to read the PIN * from a command. However, the pkcs11_parse_uri() function does * not interpret this field in any way. */ char *pinfile; } pkcs11_uri_t; We need only one function for parsing the URI, and one function to free the URI structure. All other functions are both auxiliary and static. The pkcs11_parse_uri() function takes a string with the PKCS#11 URI and fills up a structure allocated by the caller. pkcs11_free_uri() frees allocated fields but does not attempt to free the structure itself. int pkcs11_parse_uri(const char *str, pkcs11_uri_t *uri); void pkcs11_free_uri(pkcs11_uri_t *uri); Return codes are defined: #define PK11_URI_OK 0 #define PK11_URI_INVALID 1 - the string begins with the "pkcs11://" prefix but the URI is otherwise invalid. It contains an unknown attribute, for example. #define PK11_MALLOC_ERROR 2 - internal malloc() has failed #define PK11_URI_VALUE_OVERFLOW 3 - the PKCS#11 spec defines some limits on attributes. #define PK11_NOT_PKCS11_URI 4 - the string does not begin with the "pkcs11://" prefix at all Relevant CRs ------------ 6924687 teach libcryptoutil to parse a PKCS#11 URI 6953869 crypto framework STC-2 test suite needs a test for the PKCS#11 URI parsing Doc impact ---------- We will update the README file in usr/src/lib/libcryptoutil. Since libcryptoutil is private interface within ON it does not have its own manual page. Notes ----- We asked for feedback on the I-D on the following aliases: saag@ietf.org - IETF Security Area Advisory Group cryptoki@rsasecurity.com - PKCS#11 alias at RSA Security (PKCS#11 came from there) opensc-devel@lists.opensc-project.org - open smart card project Unfortunately, we haven't received any feedback. However, given that libcryptoutil is consolidation private we believe we can implement the current specification and make changes in the future should those be needed. Interface Stability ------------------- Private. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open --Boundary_(ID_EMTnk52n3LP9wsT+FaqKfw)-- From Nicolas.Williams@oracle.com Wed Jun 2 08:09:40 2010 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o52F9dgt002629 for ; Wed, 2 Jun 2010 08:09:40 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o52F9b9Q005318; Wed, 2 Jun 2010 08:09:38 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3E00J777G1GP00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 02 Jun 2010 08:09:37 -0700 (PDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E00FX17FZ5I90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 02 Jun 2010 08:09:36 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o52F9ZQK012293; Wed, 02 Jun 2010 15:09:35 +0000 (GMT) Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o52DbOnq021987; Wed, 02 Jun 2010 15:09:33 +0000 (GMT) Received: from abhmt020.oracle.com by acsmt353.oracle.com with ESMTP id 290445931275491367; Wed, 02 Jun 2010 08:09:27 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 02 Jun 2010 08:09:23 -0700 Date: Wed, 02 Jun 2010 10:09:17 -0500 From: Nicolas Williams Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] In-reply-to: To: Jan Pechanec Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: <20100602150917.GB9605@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A0B0209.4C06742E.02F4:SCFMA4539814,ss=1,fgs=0 References: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> User-Agent: Mutt/1.5.20 (2010-03-02) Status: RO Content-Length: 670 On Wed, Jun 02, 2010 at 04:44:11PM +0200, Jan Pechanec wrote: > one last change, hopefully. The "passphrasedialog" changed to > the "pinfile". This resulted from the codereview done on the > ef-interest@sun.com. Depending on the application, the value could be > overloaded to contain "/bin/askpass|", for example, to suggest that the > PIN should be read from the external command. Note that the URI parser function does not read the pinfile nor does it invoke the pinfile command (when it ends in a '|'). Reading the PIN is the application's job. (It'd be very unfortunate to execute random commands as a side-effect of parsing a user-provided URI!) Nico -- From Jan.Pechanec@sun.com Wed Jun 2 08:13:53 2010 Received: from sunmail6brm.central.sun.com (sunmail6brm.Central.Sun.COM [129.147.4.169]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id o52FDrlH002725 for ; Wed, 2 Jun 2010 08:13:53 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail6brm.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o52FDpGD001211 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 2 Jun 2010 10:13:52 -0500 (CDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0L3E0030T7N4VG00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 08:13:52 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0L3E00HOZ7N39GD0@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 08:13:51 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o52FDnVJ019778 for ; Wed, 02 Jun 2010 15:13:50 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L3E00I007C27600@fe-emea-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 02 Jun 2010 16:13:50 +0100 (BST) Received: from rejewski ([unknown] [10.18.138.121]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L3E008K57MUBPA0@fe-emea-09.sun.com>; Wed, 02 Jun 2010 16:13:42 +0100 (BST) Date: Wed, 02 Jun 2010 17:13:20 +0200 (CEST) From: Jan Pechanec Subject: Re: PKCS#11 URI parser for libcryptoutil [PSARC/2010/188 FastTrack timeout 05/28/2010] In-reply-to: <20100602150917.GB9605@oracle.com> Sender: Jan.Pechanec@sun.com X-X-Sender: jp161948@rejewski To: Nicolas Williams Cc: Darren J Moffat , PSARC-ext@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <201005211040.o4LAesp9002748@sac.sfbay.sun.com> <20100602150917.GB9605@oracle.com> Status: RO Content-Length: 834 On Wed, 2 Jun 2010, Nicolas Williams wrote: >On Wed, Jun 02, 2010 at 04:44:11PM +0200, Jan Pechanec wrote: >> one last change, hopefully. The "passphrasedialog" changed to >> the "pinfile". This resulted from the codereview done on the >> ef-interest@sun.com. Depending on the application, the value could be >> overloaded to contain "/bin/askpass|", for example, to suggest that the >> PIN should be read from the external command. > >Note that the URI parser function does not read the pinfile nor does it >invoke the pinfile command (when it ends in a '|'). Reading the PIN is >the application's job. (It'd be very unfortunate to execute random >commands as a side-effect of parsing a user-provided URI!) that's correct, and I also mentioned that in the final spec I sent. J. -- Jan Pechanec http://blogs.sun.com/janp