Subject: Re: [saag] i18n requirements (was: Re: NF* (Re: PKCS#11 URI slot attributes & last call))

From: Peter Gutmann <[email-masked]>
Date: Sun, 11 Jan 2015 22:26:40 +0000

Jan Pechanec <[email-masked]> writes:

>I would urge, as I think I did before, some fairly strong warnings that, at
>least until the issues are clarified in PKCS#11 itself, one should be very
>certain one knows what one is doing (and what the consequences of one's
>choices will be) if one decides to move beyond the safety and general
>understanding of the ASCII/ ISO 646/ IA5 letter and digit repertoire.

I'd go even further than that and just mandate MUST ASCII.  This is a simple
means of pointing to a PKCS #11 object, not a universal means of communicating
abstract concepts in any language known to man.  We've already gone from
"specify a path to load a PKCS #11 module" to something that's fast heading
towards being Turing-complete, if it isn't already.  The amount of code needed
to parse and process all of this is getting frightening, not to mention the
semantics of dealing with all of this (is anyone really going to care who the
manufacturer of their HSM is when they attach to it?).  The result is going to
be a bunch of partial, incompatible implementations with applications needing
to perform probing to see which attributes the driver they're talking to
supports if they go beyond anything but the basics.

Peter.

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Jan 2015 22:54:13 -0600

On Sun, Jan 11, 2015 at 05:28:30PM -0500, Salz, Rich wrote:
> > I'd go even further than that and just mandate MUST ASCII. 
> 
> I don't know if the IETF is "allowed" to do that any more, but +1 for
> the reasons you list.

I'm not sure if the IESG will agree to that, and I'm not sure if the
IETF will agree to that (well, this is an IETF LC, so we're finding
out).  The shepherd can probably give us a sense of the IESG, and we can
always come back and make it fit what the IESG wants.

As for myself, I'd rather we do something like this:

 - note that PKCS#11 used to be just-use-8

 - note that what used to interop did because of local conventions (what
   locales systems and/or user sessions use)

 - note that PKCS#11 _now_ says use-UTF-8 with no further advice

 - [therefore] note that

   a) US-ASCII is most likely to interop,
   b) where non-US-ASCII is needed then UTF-8 is most likely to interop
      (and is required by the latest PKCS#11 spec),
   c) where UTF-8 is used then one should normalize to NFC on create and
      lookup (and possibly use form-insensitive string matching).

I can't see the harm in any of those.  Requiring US-ASCII when PKCS#11
doesn't does strike me as a bit too pessimistic, but I'd be fine with
RECOMMENDing it.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sun, 11 Jan 2015 22:56:28 -0600

Do we need a liason to the OASIS PKCS#11 TC?

---

From: Randy Bush <[email-masked]>
Date: Mon, 12 Jan 2015 09:39:39 +0100

> towards being Turing-complete, if it isn't already

can you say "attack surface?"

http://www.cs.dartmouth.edu/~sergey/langsec/

randy

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 12 Jan 2015 11:56:42 +0100

On Sun, Jan 11, 2015 at 11:26 PM, Peter Gutmann
<[email-masked]> wrote:
> abstract concepts in any language known to man.

Correct, but that can be done by the OASIS PKCS #11 group, not by
IETF. Here the draft proposes a way to expose PKCS #11 objects/tokens
as a URI. It cannot mandate the format of the PKCS #11 attributes a
module will contain.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 11 Jan 2015 17:28:30 -0500

> I'd go even further than that and just mandate MUST ASCII. 

I don't know if the IETF is "allowed" to do that any more, but +1 for the reasons you list.

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 12 Jan 2015 09:54:23 -0500

> Do we need a liason to the OASIS PKCS#11 TC?

Interesting idea.  You volunteering? :)

I'd nominate Peter.  Also because one of the main drivers in that WG is Tim Hudson, the next island over...

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Jan 2015 10:38:56 -0500

--On Monday, January 12, 2015 09:39 +0100 Randy Bush
<[email-masked]> wrote:

>> This is a simple means of pointing to a PKCS #11 object, not
>> a universal means of communicating abstract concepts in any
>> language known to man.  We've already gone from "specify a
>> path to load a PKCS #11 module" to something that's fast
>> heading towards being Turing-complete, if it isn't already
> 

Randy,

As I'm certain you know but others reading this probably don't,
this is symptomatic of an extremely general problem with i18n.
As with "more security" or "more privacy", "internationalization
good, ASCII-only bad" can easily pass from a legitimate and
important issue and goal into slogans and political correctness.
The problem is almost identical to the security one: doing
things well is hard, retrofitting into something that wasn't
designed with security/i18n in mind is _much_ harder, and there
is a permanent shortage of both pixie dust and magical
invocations with sufficient power to solve the problems.

As with protocols designed without security, taking something
that was designed for ASCII and with no thought for i18n issues,
either becomes a matter of very careful analysis or, as you
suggest, crude efforts to retrofit something don't solve the
i18n problems and, as you point out, often broaden the attack
surface.  We really need to get better at asking whether a given
piece of protocol actually needs characters outside the ASCII
repertoire and, if it does, to find the expertise and make the
investments needed to get it right.

Security-related protocols that increase the security risks,
whether in the name of i18n or something else, do not appear to
me to be the way we should be going.

It is clear to me that investment hasn't been made here.  It is
almost as clear that the problem lies with the PKCS specs and
not with this particular document.    What to do about it is
another matter, but it seems to me that "ASCII only until
PKCS#11 itself is adequately revised" is a plausible possibility.

best,
    john

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Jan 2015 11:13:01 -0600

> Interesting idea.  You volunteering? :)

Not if it meant having to be a member of the TC.  Otherwise: maybe.

> is Tim Hudson, the next island over...

That seems fair :)  Also, IIUC Peter has participated in the TC, and
certainly he has participated here.

Nico
--

---

From: Jan Pechanec <[email-masked]>
Date: Mon, 12 Jan 2015 09:16:46 -0800 (PST)

>as a URI. It cannot mandate the format of the PKCS #11 attributes a

	hi Nikos, I agree with Nico that RECOMMENDed for ASCII use in 
labels would be fine.  I'm gonna leave the new text for the new draft 
18 discussing issues with the PKCS#11 spec not being clear about how 
to normalize UTF-8 encoded Unicode characters, and what is our 
recommendation with regard to that.  I will revisit it today and send 
a new version draft for draft 18 here.  J.

-- 
Jan Pechanec <[email-masked]>

---

From: Jan Pechanec <[email-masked]>
Date: Mon, 12 Jan 2015 12:00:07 -0800 (PST)

>abstract concepts in any language known to man.  We've already gone from

	hello Peter, thank you for the feedback, I've made it 
RECOMMENDED to use US-ASCII only for labels/names but as noted by 
others, we cannot really make it REQUIRED and still support the 
PKCS#11 spec use of UTF-8.

>manufacturer of their HSM is when they attach to it?).  The result is going to

	for tokens that are guaranteed unique, combination of the 
manufacturer ID string and the token serial number makes the token 
identification unique which may be important when used from the 
configuration files, for example (on a command line though, I'd rather 
use a token name and be warned if there are more of those of the same 
name).

	I've just filed draft 18 which addresses issues discussed on 
the use of characters outside of the US-ASCII character set.  The diff 
is as follows:

http://www.ietf.org/rfcdiff?url1=draft-pechanec-pkcs11uri-17&url2=draft-pechanec-pkcs11uri-18

	best regards, Jan.

---

From: Pete Resnick <[email-masked]>
Date: Mon, 12 Jan 2015 17:36:21 -0600

On 1/11/15 10:54 PM, Nico Williams wrote:

> I'm not sure if the IESG will agree to that...

Given that this particular member of the IESG has (successfully) argued 
vehemently for ASCII-only on multiple occasions in the recent past, I 
would say that your worries on that score are overdone. :-)

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Jan 2015 18:08:59 -0600

On Mon, Jan 12, 2015 at 05:36:21PM -0600, Pete Resnick wrote:
> Given that this particular member of the IESG has (successfully)
> argued vehemently for ASCII-only on multiple occasions in the recent
> past, I would say that your worries on that score are overdone. :-)

Well alright.  I'd love to see a set of guidelines for I18N activities.

When should we try to support Unicode, and when should we not?  Is it
one of those "I know it when I see it" kinds of guidelines?  That
wouldn't be useful enough :(

Mind you, IIRC PKCS#11 didn't even say anything about ASCII before.
Token labels and such used to be fixed-sized octet strings containing
character data.  Jan can correct me if I'm wrong.  I'm not sure even
saying "ASCII-only" would necessarily be safe in that case...

Fortunately the OASIS PKCS11 TC has clarified that these are UTF-8;
unfortunately they left other I18N details out.

Nico
--

---

From: Jan Pechanec <[email-masked]>
Date: Mon, 12 Jan 2015 16:45:57 -0800 (PST)

>unfortunately they left other I18N details out.

	hi Nico, the PKCS#11 specification says those strings are 
UTF-8 back in the last version that is still current (2.20) from 2004 
(didn't check earlier versions).  I don't think that OASIS PKCS11 TC 
has made any changes in that area to upcoming 2.40 and issues of 
normalization have never been brought up there either; I talked about 
it to Valerie Fenwick, one of the chairs of OASIS PKCS11 TC.

	I think that saying that characters from US-ASCII set SHOULD 
be used for labels and names since the PKCS#11 spec is not clear about 
the normalization should be safe here.

	which is what I did in draft 18 I've filed today and it 
contains the changes on how to deal with UTF-8 which have been 
discussed in the last couple of weeks.

https://tools.ietf.org/rfcdiff?url2=draft-pechanec-pkcs11uri-18.txt

	cheers, Jan.

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Jan 2015 18:59:13 -0600

On Mon, Jan 12, 2015 at 04:45:57PM -0800, Jan Pechanec wrote:
> (didn't check earlier versions).  [...]

Huh.  Why did I remember octet strings??  Version 2.01 (1997) did have
plain octet strings with no character set nor codeset defined.  But
still, 2004 is pretty late.

> the normalization should be safe here.

Yes.

Nico
--

---

From: Jan Pechanec <[email-masked]>
Date: Mon, 12 Jan 2015 17:06:38 -0800 (PST)

>still, 2004 is pretty late.

	it is, and version 2.30 from 2009 still under the control of 
RSA Labs was only ever draft.  Version 2.40 seems to be very close 
from becoming a new version though.

---

From: John C Klensin <[email-masked]>
Date: Mon, 12 Jan 2015 22:41:01 -0500

--On Monday, January 12, 2015 18:08 -0600 Nico Williams
<[email-masked]> wrote:

>> Given that this particular member of the IESG has
>> (successfully) argued vehemently for ASCII-only on multiple
>> occasions in the recent past, I would say that your worries
>> on that score are overdone. :-)
> 

So would we all.  RFC 2277 was supposed to provide some guidance
but is now badly obsolete in many different ways, including
exhibiting how little we knew about some things at the time.  We
have, I hope, learned a lot, but see below.

> When should we try to support Unicode, and when should we not?
> Is it one of those "I know it when I see it" kinds of
> guidelines?  That wouldn't be useful enough :(

Let me suggest a general way of thinking about things -- maybe
not quite a "guideline".  Especially for security-type
protocols, make sure there is a substantive reason, presumably
connected to users and user experience, for it to be necessary
to go beyond ASCII.  I really do mean "necessary": if it is just
a good idea in principle or a maybe-nice-to-have or "maybe
someone will want this some day", skip it because adding i18n
capabilities _will_ make correct and predictable implementations
more difficult and _will_ increase the number and range of
attack opportunities.   

> Mind you, IIRC PKCS#11 didn't even say anything about ASCII
> before. Token labels and such used to be fixed-sized octet
> strings containing character data.  Jan can correct me if I'm
> wrong.  I'm not sure even saying "ASCII-only" would
> necessarily be safe in that case...

And that reinforces my view that the real, underlying, problem
here has to be fixed in PKCS#11, not in anything the IETF puts
on top of it.  Only they can fix the problems; we can, at best,
mitigate the damage.

> Fortunately the OASIS PKCS11 TC has clarified that these are
> UTF-8; unfortunately they left other I18N details out.

It appears to me that what they have said puts their level of
understanding of the various issues somewhat behind where we
were when RFC 2277 was written in 1997.  

    john

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Jan 2015 16:36:30 -0600

> more difficult and _will_ increase the number and range of

Yes, I18N is all about UIs and the UX.

Clearly, if a character string isn't a UI element, and is never a
visible aspect of the UX, then it is a great candidate for being made
US-ASCII only.  Indeed, we *should* make all such strings US-ASCII only.

That much is obvious, and whether or not something is part of the UI is
an objective measure with relatively little room for doubt.

But there are UI elements that could reasonably be constrained to
US-ASCII (because the world over, people manage to deal with US-ASCII
character strings in various parts of their UIs).  The tricky part is
deciding what UI elements (or things leaking into them) qualify.

For example, a "manufacturer" name in PKCS#11 could reasonably be
constrained to US-ASCII only.  Right?  Well, maybe a French -say-
manufacturer might object.

An interesting distinction here might be: name or identifier?
Identifiers (appearing in UIs) -> US-ASCII.  Names -> Unicode.

Token and object labels seem a lot like identifiers in the use cases I
expect.  But I can't be certain that they would never be expected to
contain names.

Manufacturer names really are names, no?

These are decisions that we can make that can anger people who are not
participating here today.

Yes.

But look, PKCS#11 is a thing with a low count of character strings.
Mostly things will be looked for with equivalence semantics, and
form-insensitive Unicode string comparison will do for that (at the
expense of having the code for it), as will plain old octet string
comparison (because we can expect happy input method output form
agreement accidents).

I think Jan's text is fine.  I don't mean to belabor this thread.
I'm now only commenting on the more general matter of when we should be
happy to settle for less than the full I18N treatment.

> were when RFC 2277 was written in 1997.  

Yes, but it's also fair to note the above, that this is the sort of case
where a low-effort I18N ("say UTF-8; say nothing about anything else")
seems likely to be good enough for most implementors and users.

Nico
--