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(_at_)cryptonector(_dot_)com>
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
--