> On 31 Dec 2014, at 09:25, Nico Williams <nico@xxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail