On Wed, Dec 31, 2014 at 10:09:39AM +0100, Patrik Fältström wrote: > > On 31 Dec 2014, at 09:25, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > > 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. As with filesystems, the "processes" creating and accessing the resource are all clients. There are no servers that can make right, therefore we might as well not speak of them :) (We're agreeing.) > 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. Yes. The question is whether we should in this case. I'm in favor of saying "do form-insensitive comparison". I'd settle for "always normalize to NFC when creating PKCS#11 resources" because, after all, that's what IRIs need anyways, it's just that a PKCS#11 URI-using app might not be in a position to make "normalize on create" happen. OTOH, I think this is a minor issue, so if reaching consensus is hard, then I say "say nothing", normatively anyways. However, you're right that as far as Security Considerations go, we can't say nothing. > Look at UTF-8 for example. Indeed. We make things better. > 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. Yes, we agree :) > 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,...)? No, it will have security considerations regardless. The only way to help that is to force normalization on create, but as I say, that's not something this spec can cause to happen or assume has happened. > 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. Yes. Nico --