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

Jaroslav Imrich <jaroslav.imrich@gmail.com> Sun, 04 January 2015 11:40 UTC

Return-Path: <jaroslav.imrich@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CE01A8739; Sun, 4 Jan 2015 03:40:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y_aQeUV0qYE; Sun, 4 Jan 2015 03:40:24 -0800 (PST)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A96DC1A8710; Sun, 4 Jan 2015 03:40:23 -0800 (PST)
Received: by mail-ie0-f171.google.com with SMTP id ar1so18248306iec.2; Sun, 04 Jan 2015 03:40:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fh4zSZq1irDelJskvgekorGVjTjzMaEVMyrHRwSkgcY=; b=zpFhSSRXkGIDN24IePuNnVJ7647gnFTv2oD7ZuzI9A0MyPGycL2maGl/a1EJ0F0ZWk QE8O2tAFZ4WqeIJbX2Zpq+w+YH2gZmOFZzCAraSIokJgZ8tOdvtyB9Bt0utc/K+OU4pQ Ls0xnQFo2qDb5+Yx9g6HS0ynuIX0D+parxWHVVImEOVT04q8oV1zoU8KXMm9LZpZar2U e1cUVjY86eA9WzMgNBHM9XKNsqRZ0c8x9WzKcR7LdNRQjr0uw6LW/uIxuqrBhg3sWc4i il6bpVuk6bB/FyiUv4stZe+z6WyELqpNG5mo7oYQwrcASiKDl+vcNATOd1De1w6aotqN J/eg==
MIME-Version: 1.0
X-Received: by 10.50.8.7 with SMTP id n7mr6584503iga.16.1420371622717; Sun, 04 Jan 2015 03:40:22 -0800 (PST)
Received: by 10.50.111.161 with HTTP; Sun, 4 Jan 2015 03:40:22 -0800 (PST)
In-Reply-To: <alpine.GSO.2.00.1501032124490.6923@keflavik>
References: <CAK3OfOgm_ZYj-rY+4ExZzY8KY4G3rz2KLrZ8hQJi7ZUR4yiP0Q@mail.gmail.com> <alpine.GSO.2.00.1412300946340.4549@keflavik> <CAK3OfOha9qu=uDtqwDTdV78waLMaorYq0T6cq1YX3VzQn2OpKA@mail.gmail.com> <A4CC6CEC-D17E-4235-B615-9D2AD88096D4@frobbit.se> <20141231070328.GK24442@localhost> <B08B813F-B8B4-49F1-A0B9-60F322C8E9C7@frobbit.se> <20141231074641.GM24442@localhost> <947CA101-D717-4B56-8EEE-84B3A53BF4A1@frobbit.se> <20141231082551.GN24442@localhost> <E4837FDB76D5ACDEB1C568DF@192.168.1.128> <20150102030130.GN24442@localhost> <alpine.GSO.2.00.1501032124490.6923@keflavik>
Date: Sun, 4 Jan 2015 12:40:22 +0100
Message-ID: <CAB6OCMs=iZcn=1LBLEAs606ani9k6B6VANj4iH8QAqnjNb5Ygg@mail.gmail.com>
Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))
From: Jaroslav Imrich <jaroslav.imrich@gmail.com>
To: Jan Pechanec <jan.pechanec@oracle.com>
Content-Type: multipart/alternative; boundary=089e013c660e057097050bd20aa3
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/iFaZ9DK88Wc2BX67loBwhNx38-I
X-Mailman-Approved-At: Mon, 05 Jan 2015 08:09:24 -0800
Cc: Darren J Moffat <Darren.Moffat@oracle.com>, ietf@ietf.org, =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <paf@frobbit.se>, saag@ietf.org, John C Klensin <john-ietf@jck.com>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Jan 2015 11:40:28 -0000

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 <jan.pechanec@oracle.com>
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 <jan.pechanec@oracle.com>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>
>