Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))

[Jaroslav Imrich <[e-mail]>]

Hello Jan,

the text mentions "NFC" but I was unable to find any pointer or reference
to its definition. I was not familiar with the term before so I think
reference in the text would be helpful.

Regards, Jaroslav


On Sun, Jan 4, 2015 at 6:58 AM, Jan Pechanec <[e-mail]>
wrote:

> On Thu, 1 Jan 2015, Nico Williams wrote:
>
>         Nico, many thanks for the drafted text and also to Patrik and
> John for discussing it.
>
>         I've updated the draft in sections on URI matching guidelines,
> URI comparision, added a new section on I18n, and added a new paragraph
> to the Security considerations.  Individial diffs inline, a draft for
> new draft 18 attached (draft-pechanec-pkcs11uri-18-v1.txt).
>
> >I think we could use some text like this:
> >
> >   PKCS#11 does not specify a canonical from for UTF-8 string slots in
> >   the API.  This presents the usual false negative and false positive
> >   (aliasing) concerns that arise when dealing with unnormalized
> >   strings.  Because all PKCS#11 items are local and local security is
> >   assumed, these concerns are mainly about usability.
> >
> >   In order to improve the user experience, applications that create
> >   PKCS#11 objects or otherwise label tokens, SHOULD normalize labels to
> >   NFC.  For the same reason PKCS#11 libraries, slots (token readers),
> >   and tokens SHOULD normalize their names to NFC.  When listing
> >   libraries, slots, tokens, or objects, an application SHOULD normalize
> >   their names to NFC.  When matching PKCS#11 URIs to libraries, slots,
> >   tokens, and/or objects, applications may use form-insensitive Unicode
> >   string comparison for matching, as the objects might pre-date these
> >   recommendations).
>
>         I've created "Internationalization Considerations" section and
> put the text above there after I slightly modified it.  I wanted to
> mention CK_UTF8CHAR type so that it's clear what is discussed.
>
> 768     6.  Internationalization Considerations
>
> 770        The PKCS#11 specification does not specify a canonical form for
> 771        strings of characters of the CK_UTF8CHAR type.  This presents
> the
> 772        usual false negative and false positive (aliasing) concerns that
> 773        arise when dealing with unnormalized strings.  Because all
> PKCS#11
> 774        items are local and local security is assumed, these concerns
> are
> 775        mainly about usability.
>
> 777        In order to improve the user experience, applications that
> create
> 778        PKCS#11 objects or label tokens, SHOULD normalize labels to
> NFC.  For
> 779        the same reason PKCS#11 libraries, slots (token readers), and
> tokens
> 780        SHOULD normalize their names to NFC.  When listing PKCS#11
> libraries,
> 781        slots, tokens, and/or objects, an application SHOULD normalize
> their
> 782        names to NFC.  When matching PKCS#11 URIs to libraries, slots,
> 783        tokens, and/or objects, applications MAY use form-insensitive
> Unicode
> 784        string comparison for matching, as those might pre-date these
> 785        recommendations.  See also Section 3.5.
>
>         in section 3.5 on URI Matching Guidelines, I've added the
> following as the last paragraph of the section (it was based on John's
> note from his last email).  This paragraph might not be necessary there
> and the first part could be moved to the I18N section but I think it's
> good to put it to where attribute matching is discussed so that it is
> not easily overlooked.
>
> 513        As noted in Section 6, the PKCS#11 specification is not clear
> about
> 514        how to normalize UTF-8 encoded Unicode characters [RFC2279].
> Those
> 515        who discover a need to use characters outside the ASCII
> repertoire
> 516        should be cautious, conservative, and expend extra effort to be
> sure
> 517        they know what they are doing and that failure to do so may
> create
> 518        both operational and security risks.  It means that when
> matching
> 519        UTF-8 string based attributes (see Table 1) with such
> characters,
> 520        normalizing all UTF-8 strings before string comparison may be
> the
> 521        only safe approach.  For example, for objects (keys) it means
> that
> 522        PKCS#11 attribute search template would only contain attributes
> that
> 523        are not UTF-8 strings and another pass through returned objects
> is
> 524        then needed for UTF-8 string comparison after the normalization
> is
> 525        applied.
>
> >Then later in the security considerations section, add something like:
> >
> >   PKCS#11 does not authenticate devices to users; PKCS#11 only
> >   authenticates users to tokens.  Instead, local and physical security
> >   are demanded: the user must be in possession of their tokens, and
> >   system into whose slots the users' tokens are inserted must be
> >   secure.  As a result, the usual security considerations regarding
> >   normalization do not arise.  For the same reason, confusable script
> >   issues also do not arise.  Nonetheless, it is best to normalize to
> >   NFC all strings appearing in PKCS#11 API elements.
>
>         I've added the following to the Security Considerations
> section (again, slightly modified, I'd rather not use "PKCS#11" as
> an alias for the specification):
>
> 807        The PKCS#11 specification does not provide means to authenticate
> 808        devices to users; it only allows to authenticate users to
> tokens.
> 809        Instead, local and physical security are demanded: the user
> must be
> 810        in possession of their tokens, and system into whose slots the
> users'
> 811        tokens are inserted must be secure.  As a result, the usual
> security
> 812        considerations regarding normalization do not arise.  For the
> same
> 813        reason, confusable script issues also do not arise.
> Nonetheless, it
> 814        is best to normalize to NFC all strings appearing in PKCS#11 API
> 815        elements.  See also Section 6.
>
>         on top of that, I've added the following sentence to 3.6. PKCS#11
> URI
> Comparison section:
>
> 532        strictly avoiding false positives.  When working with UTF-8
> strings
> 533        with characters outside the ASCII character sets, see important
> 534        caveats in Section 3.5 and Section 6.
>
>         the attribute Table 1 now also states which attributes are
> UTF-8 strings so that it's clear without consulting the spec.
>
>         thank you, Jan.
>
> --
> Jan Pechanec <[e-mail]>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>
>