[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Fwd: Re: [pkcs11-comment] Character set for PIN
My reply to David. -------- Forwarded Message -------- Subject: Re: [pkcs11-comment] Character set for PIN Date: Tue, 4 Oct 2016 11:26:40 -0700 From: Valerie Fenwick <valerie.fenwick@oracle.com> Organization: Oracle Corporation To: pkcs11-comment@lists.oasis-open.org Hi David - On 10/3/2016 1:25 AM, Woodhouse, David wrote:
The specification says in §1.3 that "The CK_UTF8CHAR data type holds UTF-8 encoded Unicode characters as specified in RFC2279. UTF-8 allows internationalization while maintaining backward compatibility with the Local String definition of PKCS #11 version 2.01." Referring back to Table 3 in PKCS#11 v2.01, I observe that the legacy 8-bit character sets were (quite sensibly) NEVER allowed to be in a PIN. However, application authors are often very lax when it comes to character set handling. I'm sure plenty of them would look at the words "compatibility with Local String", and just blithely go ahead and use a local legacy 8-bit character set. In fact, many are so lax about character sets that they'd just do it anyway, without *even* reading and misinterpreting those words. We should make it clearer. Can we add wording to the spec which says that that functions such as C_SetPIN() and C_InitPIN() MUST return CKR_ARGUMENTS_BAD if the input is not valid UTF-8. Perhaps also C_Login() too? Or failing that, can we at *least* add such to the Usage Guide, noting that applications must convert user input from their local character set to UTF-8 for the purpose of calling C_Login() and similar functions.
As you've noted, there may have been lax programmers out there, and we certainly generally do not want to break compatibility with older implementations - but, a note in the usage guide may make sense. I will
bring this up to our new usage guide editor.
In the shorter term, I am drafting a best practice document for client applications which use X.509 certificates, which includes "thou shalt silently do the right thing when the user gives you a RFC7512 PKCS#11 URI instead of a filename". In that document, can I state that applications MUST convert a PIN to UTF-8 and not try the local charset? For PKCS#8 I do already recommend to *try* UTF-8 and then fall back to the legacy 8-bit local character set. But for PKCS#11 where trying the wrong PIN may lock the token, I am very reluctant to suggest that. In my draft, I also set out a method of locating objects in the available tokens, given a PKCS#11 URI. I'd very much welcome any feedback on that too (or indeed any part). Section 8.1 of http://david.woodhou.se/draft-woodhouse-cert-best-practice.html
Thank you for sharing - I will share with the wider TC and hopefully you will hear some comments.
Valerie -- Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. -- This publicly archived list offers a means to provide input to the OASIS PKCS 11 TC. In order to verify user consent to the Feedback License terms and to minimize spam in the list archive, subscription is required before posting. Subscribe: pkcs11-comment-subscribe@lists.oasis-open.org Unsubscribe: pkcs11-comment-unsubscribe@lists.oasis-open.org List help: pkcs11-comment-help@lists.oasis-open.org List archive: http://lists.oasis-open.org/archives/pkcs11-comment/ Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf List Guidelines: http://www.oasis-open.org/maillists/guidelines.php Committee: http://www.oasis-open.org/committees/pkcs11 Join OASIS: http://www.oasis-open.org/join/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]