Projects/ResponderForPKINIT - Revision history

Nalin: /* Tentative Implementation */

2013-07-18T13:29:53Z

‎Tentative Implementation

Nalin: /* Tentative Implementation */

2013-02-22T22:00:43Z

‎Tentative Implementation

Nalin: /* Testing */

2013-02-17T01:57:10Z

‎Testing

Nalin: /* Tentative Implementation */

2013-02-17T01:50:30Z

‎Tentative Implementation

Nalin: /* Tentative Implementation */

2013-02-05T18:31:33Z

‎Tentative Implementation

Nalin: /* Tentative Implementation */

2013-01-24T23:22:21Z

‎Tentative Implementation

Nalin: /* Tentative Implementation */

2013-01-24T23:19:48Z

‎Tentative Implementation

Nalin: /* Tentative Implementation */

2013-01-24T23:18:48Z

‎Tentative Implementation

Nalin: /* Tentative Implementation */

2013-01-24T18:59:31Z

‎Tentative Implementation

Nalin: /* Tentative Implementation */

2012-12-21T20:34:37Z

‎Tentative Implementation

@@ Line 25: / Line 25: @@
 * Teach crypto_load_certs() to change its behavior to return a specific error to indicate when a given identity's keying material was protected by a PIN or password.
 * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass.  Special care will be needed for "DIR" identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual "FILE" identities internally, and for "PKCS11" identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.
-* In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback.  Suggested sample challenge for a ''pkinit'' question:
+* In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, and any PIN-related warnings, to pass to the responder callback.  Suggested sample challenge for a ''pkinit'' question:
-    {"identities": ["PKCS12:/path/to/blah", "FILE:/path/to/cert,/path/to/key"], 'token-flags':{}}
+    {"PKCS12:/path/to/blah": 0, "FILE:/path/to/cert,/path/to/key": 0, "PKCS11:module=opensc-pkcs11.so:slotid=1:token=My Card": 4}
 Suggested sample answer:
-    {"identities": {"PKCS12:/path/to/blah": "foo", "FILE:/path/to/cert,/path/to/key": "bar"}}
+    {"PKCS12:/path/to/blah": "foo", "FILE:/path/to/cert,/path/to/key": "bar"}
-The ''token-flags'' object a subset of the members of ''identities'' as keys, and numbers corresponding to token flags as their values.  These flags convey the status of a token's pin, and will be set to zero or more of the flags ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_COUNT_LOW'', ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_FINAL_TRY'', and ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_LOCKED''.
+The challenge is an object whose keys are identity names, with their associated values being numbers corresponding to token flags.  These flags convey the status of a token's pin, and will be set to zero or more of the flags ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_COUNT_LOW'', ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_FINAL_TRY'', and ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_LOCKED''.
 * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer.  If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.
 * Helper functions for parsing the challenge into a structure (''krb5_responder_pkinit_get_challenge'', ''krb5_responder_pkinit_challenge_free'') and setting answers (''krb5_responder_pkinit_set_answer'') will also be added.

@@ Line 32: / Line 32: @@
 The ''token-flags'' object a subset of the members of ''identities'' as keys, and numbers corresponding to token flags as their values.  These flags convey the status of a token's pin, and will be set to zero or more of the flags ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_COUNT_LOW'', ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_FINAL_TRY'', and ''KRB5_RESPONDER_PKINIT_FLAGS_TOKEN_USER_PIN_LOCKED''.
 * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer.  If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.
-* Helper functions for parsing the challenge into a structure (''krb5_responder_pkinit_get_challenge'', ''krb5_responder_pkinit_challenge_free'') and setting at most one answer (''krb5_responder_pkinit_set_answer'') will also be added.
+* Helper functions for parsing the challenge into a structure (''krb5_responder_pkinit_get_challenge'', ''krb5_responder_pkinit_challenge_free'') and setting answers (''krb5_responder_pkinit_set_answer'') will also be added.
 ==Testing==

@@ Line 39: / Line 39: @@
 * We'll need a test program that lets us specify both that a particular response item is expected, and which response to supply for it, and which does not supply a prompter callback.
 * We'll need to run tests using both encrypted and unencrypted copies of the keying material.
 ==Documentation==

@@ Line 26: / Line 26: @@
 * Break pkinit_identity_initialize() up into two passes, one which calls crypto_load_certs() with this flag and returns immediately, to suss out which identities have protected keying information, and one which works like the current version, except that it will skip over anything which was loaded in the first pass.  Special care will be needed for "DIR" identities, as the two-pass logic will have to be applied at the level where it's resolved things down to individual "FILE" identities internally, and for "PKCS11" identities, which may only specify a module, but which will need to be able to unambiguously refer to specific tokens and/or slots.
 * In pkinit_clnt.c, add a client_prep_questions method which calls the first pass of pkinit_identity_initialize(), and which puts together a list of the identities which couldn't be loaded, due to a PIN or password being required, to pass to the responder callback.  Suggested sample challenge for a ''pkinit'' question:
-    {"identities": ["PKCS12:/path/to/blah", "FILE:/path/to/cert,/path/to/key"]}
+    {"identities": ["PKCS12:/path/to/blah", "FILE:/path/to/cert,/path/to/key"], 'token-flags':{}}
 Suggested sample answer:
     {"identities": {"PKCS12:/path/to/blah": "foo", "FILE:/path/to/cert,/path/to/key": "bar"}}
 * In the second pass of pkinit_identity_initialize(), use values provided in the answer, if there is one, to load identity information from locations in the answer.  If no answer was available, use the prompter callback, as is done now, to solicit PINs and passwords for identities listed in the challenge.
 ==Testing==

@@ Line 32: / Line 32: @@
 '''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low.  Should the question format be modified to accommodate and carry this information?  Would adding a ''warnings'' object, with keys matching elements from the ''identities'' array, with their corresponding warnings as values, be simplest?
-    {"identities": ["PKCS12:/path/to/blah"], "warnings": {"PKCS12:/path/to/blah": "PIN count low"}}
+    {"identities": ["PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1"], "warnings": {"PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1": "PIN count low"}}
 This is rejected because the warning text is still too hard to process in a dependable way, particularly if we have to add possible values.  Another option is to just expose the "flags" value from the token's CK_TOKEN_INFO, if such flags are applicable, and leave it to the calling application to interpret the value:
-    {"identities": ["PKCS12:/path/to/blah"], "token-flags": {"PKCS12:/path/to/blah": 76}}
+    {"identities": ["PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1"], "token-flags": {"PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1": 71036}}
 Another option is to expose selected flags as keys in an object which maps them to booleans:
-    {"identities": ["PKCS12:/path/to/blah"], "info": {"PKCS12:/path/to/blah": {"user-pin-locked": false, "user-pin-count-low": false}}}
+    {"identities": ["PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1"], "token-flags": {"PKCS11:module_name=pkcs11.so,token=MacGuffin (token),slotid=1": {"user-pin-locked": false, "user-pin-count-low": false}}}
 '''Topic for discussion''': should helper functions, similar to krb5_responder_otp_get_challenge(), be added?  If so, what should that API look like?  '''YES'''; the API will look almost exactly like the krb5_responder_otp_XXX set of functions, but the type of the data structure which it returns will need to reflect what is exposed in the challange, and how it is exposed.
 '''Topic for discussion''': how will we go about integrating testing with PKCS11 modules into the self-test suite?
 ==Testing==

← Older revision		Revision as of 23:18, 24 January 2013
Line 32:		Line 32:

	'''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low. Should the question format be modified to accommodate and carry this information? Would adding a ''warnings'' object, with keys matching elements from the ''identities'' array, with their corresponding warnings as values, be simplest?		'''Topic for discussion''': when using a PKCS11 client identity, the OpenSSL version of the plugin will read the token's info and add, to the text which it passes to the prompter callback, text indicating if the PIN is locked, is on its last try, or is low. Should the question format be modified to accommodate and carry this information? Would adding a ''warnings'' object, with keys matching elements from the ''identities'' array, with their corresponding warnings as values, be simplest?
		+	{"identities": ["PKCS12:/path/to/blah"], "warnings": {"PKCS12:/path/to/blah": "PIN count low"}}
		+	This is rejected because the warning text is still too hard to process in a dependable way, particularly if we have to add possible values. Another option is to just expose the "flags" value from the token's CK_TOKEN_INFO, if such flags are applicable, and leave it to the calling application to interpret the value:
		+	{"identities": ["PKCS12:/path/to/blah"], "token-flags": {"PKCS12:/path/to/blah": 76}}
		+	Another option is to expose selected flags as keys in an object which maps them to booleans:
		+	{"identities": ["PKCS12:/path/to/blah"], "info": {"PKCS12:/path/to/blah": {"user-pin-locked": false, "user-pin-count-low": false}}}
		⚫	'''Topic for discussion''': should helper functions, similar to krb5_responder_otp_get_challenge(), be added? If so, what should that API look like? '''YES'''

⚫	'''Topic for discussion''': should helper functions, similar to krb5_responder_otp_get_challenge(), be added? If so, what should that API look like?
		+	'''Topic for discussion''': how will we go about integrating testing with PKCS11 modules into the self-test suite?

	==Testing==		==Testing==