OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Character set for PIN


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.

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

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@intel.com                              Intel Corporation

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]