Re: NF* (Re: PKCS#11 URI slot attributes & last call)

> On 31 Dec 2014, at 09:25, Nico Williams <nico(_at_)cryptonector(_dot_)com> 
> wrote:
>
> > So, given your choice on server side matching, what are the
> > requirements on client side?
> There's no network protocol here.  There's an API and applications
> interoperating over IPC ("cut-n-paste").
>
> Of course, the issues are the same, it's just that there's no "server"
> to consider.  It's all as good as "clients".  Unlike IDNA, it's all
> UTF-8, all the time, so that form-insensitive can work.
Well, the definition of a URI like in this case in reality define a protocol 
with a client and server, if we think about the case when the URI is used. 
Someone create a URI (by typing, speaking, OCR:ing, copying) and use it to 
reach a resource.

So the issues are the same.

Regarding "the PKCS#11 does not talk about the issue, so why would IETF" is a 
question I think has a clear answer. IETF have in many cases created profiles, 
or let me say "interpretations" of definitions made elsewhere. Simply because 
IETF do not think the specification is crisp enough.

Look at UTF-8 for example.

You also write:

> IOW, what to do depends on the application.  For filesystems I say: be
> form-preserving-form-insensitive.  For IDNA there's no choice but to go
> with clients-must-normalize.  Each app will be different.

Sure, that is my point.

What you say is that the IETF use of PKCS#11, without any specification of 
normalisation, mapping or otherwise, will not have any security implications 
what so ever regardless of what an application do (i.e. one party participating 
using one normalisation form, another do PRECIS mapping, a third do NFC,...)?

That is what I see you write, and if either I understand you wrong, or if that 
is not what you are saying, then a text must be created and added that explain 
the pitfalls -- at least as part of the security considerations section if not 
in the specification on how PKCS#11 is to be used.

   Patrik

signature.asc
Description: Message signed with OpenPGP using GPGMail