Fwd: Re: [pkcs11-comment] Character set for PIN

[Valerie Fenwick <valerie.fenwick@oracle.com>]

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/