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

[Nico Williams <[e-mail]>]

On Wed, Dec 31, 2014 at 10:09:39AM +0100, Patrik Fältström wrote:
> > On 31 Dec 2014, at 09:25, Nico Williams <[e-mail]> 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
--