Re: [pkcs11] space padded strings

[Oscar So <oscar.so@oracle.com>]

FYI


Michael StJohn and Wan-Teh replied:

-------------
On 06/18/14 12:06 PM, StJohns, Michael wrote:
> Hi Oscar, I've mostly dropped out of the pkcs11 mess.  That said - I
> believe this is to allow for single allocation c structs.  E.g. Fixed
> length byte arrays rather than (char *) fields allows for a contiguous
> allocation of memory.  Also, the termination convention of null is not
> universal.
>
> In any event, the blank padding is a convention - you can put any valid
> UTF8 character where you want it and interpret the field how you want
> without violating the standard.  But the field is the complete 32 or 64
> UTF8 bytes and is managed that way.
>
> There are a few java pkcs11 implementations that incorrectly treat this
> as a string rather than a byte or character array.
>
> Mike
-----------



I don't know why. I suspect only PKCS #11 old timers such as Bob
Relyea know why.

In my opinion the white space padding is inconvenient. It is fine to
specify a maximum size for these strings, but I think they should be
normal, null-terminated C strings, with NO white space padding. I
wonder if we can make this change in PKCS #11 v3.0.

Wan-Teh






On 06/18/14 11:35 AM, Oscar So wrote:
> I asked Bob Relyea at RedHat privately, and he replied:
> -----------------
> Because the data is a fixed byte array of 32 bytes. Internally NSS turns
> it into a null terminated string, but space padding makes the PKCS #11
> string predictable (you can compare PKCS #11 strings by comparing the 32
> byte values directly). If you null terminated the string, then code that
> does direct comparison could fail because it will pick up junk after the
> null.
>
> bob
>
> -----------------
>  From my opinion, I got the same feeling that PKCS #11 will trust
> anything within the buffer of its size. And, the user has to trust all
> of them. For example, TOKEN_INFO label has size 32 bytes. Once the user
> obtain this label value from PKCS#11, the user has to trust all 32
> bytes, and can only do very limited validation on this value.
>
> Say, only the following can be detected:
> " my_name " (invalid due to a space at the front)
> "my_name JUNK JUNK " (it's invalid for our eyes only, but, it is valid
> for PKCS#11)
>
> Best,
> Oscar
>
>
>
>
>
>
>
>
> On 06/17/14 03:11 PM, Valerie Anne Fenwick wrote:
> > Hi all -
> >
> > All of the strings in PKCS11 are currently space padded and NOT Null
> > terminated. Does anyone recall the background as to why we did that?
> > Do we still need to?
> >
> > Thanks!
> >
> > Valerie