Subject: Re: [pcp] ID Indicator option

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 26 Nov 2014 17:30:38 +0000

> -----Original Message-----
> From: pcp [mailto:[email-masked]] On Behalf Of Peter Saint-Andre -
> &yet
> Sent: Tuesday, November 25, 2014 8:51 AM
> To: [email-masked]
> Subject: [pcp] ID Indicator option
> 
> Dave Thaler has asked me to take a look at the ID Indicator option in draft-
> ietf-pcp-authentication with respect to internationalization.
> 
> First, it's not clear to me exactly what the ID indicator indicates.

ID indicator will help the PCP client to pick the appropriate credentials to use with the server. 

> The spec says
> that it is "the identity of the authority that issued the credentials" and that
> "the method of generating this value is out of scope". Are there at least any
> examples of what an ID indicator might look like? 

It might look like "[email-masked]"

> For example, what kinds of
> characters are allowable in an ID indicator ?
>
> Over in the PRECIS WG, we have put a great deal of thought into the handling
> of internationalized strings within protocols. The PRECIS "IdentifierClass" is
> intended to provide the foundation for identifiers that are quite safe to use
> (e.g., by forbidding "expressive" characters such as symbols). See draft-ietf-
> precis-framework for details.
> 
> Based on what I know so far, I think that using the Username profile of the
> IdentifierClass (defined in draft-ietf-precis-saslprepbis) might make sense
> here. 

Okay, so ID Indicator will consist only of Unicode code points that conform to the "IdentifierClass" base string class defined in ietf-precis-framework and the string MUST be encoded as UTF-8.

> It maps fullwidth and halfwidth characters (common in certain East
> Asian languages), applies Unicode Normalization Form C (NFC), etc. We have
> had some debate about handling of case mapping vs.
> case preservation, and it seems likely that we will end up specifying two
> Username profiles, one with case mapping and one with case preservation
> (e.g., does an ID indicator of FooBarCity match an ID indicator of foobarcity
> during comparison operations?). As Dave pointed out in a recent message to
> this list, RFC 6943 might be consulted here as well.

Yup, it was discussed in the PCP WG meeting at IETF-91 that "Absolute" comparison algorithm will be used by the PCP client.

-Tiru

> 
> (I shall remain subscribed to this list until we work out an agreeable solution,
> so there's no need to cc me.)
> 
> Peter
> 
> --
> Peter Saint-Andre
> https://andyet.com/
> 
> _______________________________________________
> pcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcp

---

From: Dave Thaler <[email-masked]>
Date: Wed, 26 Nov 2014 20:51:07 +0000

Tiru Reddy wrote:
> > From: pcp [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> > - &yet
> > Dave Thaler has asked me to take a look at the ID Indicator option in
> > draft- ietf-pcp-authentication with respect to internationalization.
> >
> > that it is "the identity of the authority that issued the credentials"
> > and that "the method of generating this value is out of scope". Are
> > there at least any examples of what an ID indicator might look like?
> 
> > Over in the PRECIS WG, we have put a great deal of thought into the
> > handling of internationalized strings within protocols. The PRECIS
> > "IdentifierClass" is intended to provide the foundation for
> > identifiers that are quite safe to use (e.g., by forbidding
> > "expressive" characters such as symbols). See draft-ietf- precis-framework
> for details.
> >
> > Based on what I know so far, I think that using the Username profile
> > of the IdentifierClass (defined in draft-ietf-precis-saslprepbis)
> > might make sense here.
> 
> Okay, so ID Indicator will consist only of Unicode code points that conform to
> the "IdentifierClass" base string class defined in ietf-precis-framework and the
> string MUST be encoded as UTF-8.
> 
> > Asian languages), applies Unicode Normalization Form C (NFC), etc. We
> > have had some debate about handling of case mapping vs.
> > case preservation, and it seems likely that we will end up specifying
> > two Username profiles, one with case mapping and one with case
> > preservation (e.g., does an ID indicator of FooBarCity match an ID
> > indicator of foobarcity during comparison operations?). As Dave
> > pointed out in a recent message to this list, RFC 6943 might be consulted
> here as well.
> 
> Yup, it was discussed in the PCP WG meeting at IETF-91 that "Absolute"
> comparison algorithm will be used by the PCP client.

Absolute means byte-for-byte equality.  The WG actually wanted "Definite"
which means you specify what the normalization/comparison algorithm is,
and that's what we're discussing here.

-Dave

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 26 Nov 2014 13:54:24 -0700

> and that's what we're discussing here.

Right. I would suggest the Username profile of the IdentifierClass from 
draft-ietf-saslprepbis, probably the case-mapping version instead of the 
case-preserving version. (Right now the spec doesn't have both of those 
versions in it, but it will soon.)

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 26 Nov 2014 13:55:31 -0700

On 11/26/14, 1:54 PM, Peter Saint-Andre - &yet wrote:
>>> ID indicator will help the PCP client to pick the appropriate
>>> credentials to use
>>> with the server.
>>>
>>>> The spec says

Oops, that's draft-ietf-precis-saslprebis:

http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 27 Nov 2014 01:45:55 +0000

> From: Peter Saint-Andre - &yet [mailto:[email-masked]]
> Sent: Thursday, November 27, 2014 2:26 AM
> To: Dave Thaler; Tirumaleswar Reddy (tireddy); [email-masked]
> Subject: Re: [pcp] ID Indicator option
> 
> >>> credentials to use with the server.
> >>>
> >>>> The spec says
> >>>> Based on what I know so far, I think that using the Username
> >>>> profile of the IdentifierClass (defined in
> >>>> draft-ietf-precis-saslprepbis) might make sense here.
> >>>
> >>> Okay, so ID Indicator will consist only of Unicode code points that
> >>> conform to the "IdentifierClass" base string class defined in
> >>> ietf-precis-framework and the string MUST be encoded as UTF-8.
> >>>
> >>>> Asian languages), applies Unicode Normalization Form C (NFC), etc.
> >>>> We have had some debate about handling of case mapping vs.
> >>>> case preservation, and it seems likely that we will end up
> >>>> specifying two Username profiles, one with case mapping and one
> >>>> with case preservation (e.g., does an ID indicator of FooBarCity
> >>>> match an ID indicator of foobarcity during comparison operations?).
> >>>> As Dave pointed out in a recent message to this list, RFC 6943
> >>>> might be consulted
> >>> here as well.
> >>>
> >> which means you specify what the normalization/comparison algorithm
> >> is, and that's what we're discussing here.
> >
> > Right. I would suggest the Username profile of the IdentifierClass
> > from draft-ietf-saslprepbis, probably the case-mapping version instead
> > of the case-preserving version. (Right now the spec doesn't have both
> > of those versions in it, but it will soon.)

Okay, I guess it means that the PCP client will use Case-mapping rule https://tools.ietf.org/html/draft-ietf-precis-framework-20#section-5.2.3 for ID indicator comparison.

-Tiru

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 26 Nov 2014 20:25:21 -0700

> Okay, I guess it means that the PCP client will use Case-mapping rule https://tools.ietf.org/html/draft-ietf-precis-framework-20#section-5.2.3 for ID indicator comparison.

Hi Tiru,

Well, not quite, because case mapping is only one small part of the 
problem. (Yes, internationalization is hard in a messy way.)

Your message inspired me to update draft-ietf-precis-saslprepbis so that 
it defines exactly what I think the PCP WG needs:

http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-11#section-3.2

As Dave Thaler has pointed out, a "Definite" comparison algorithm 
provides a single well-defined comparison method. In the context of the 
work we've been doing in the PRECIS WG, such a comparison algorithm 
includes the following:

1. Specification of the allowable range of Unicode characters (in PRECIS 
we have narrowed this down to two string classes: the IdentifierClass 
and the FreeformClass).

2. Specification of rules for width mapping, so-called additional 
mappings (e.g., mapping of non-ASCII space characters to ASCII space), 
and case mapping vs. case preservation.

3. Specification of the Unicode normalization form to be applied 
(typically NFC).

4. Specification of how to handle strings that contain right-to-left 
characters.

5. Specification of the equivalence rules for comparison purposes 
(typically octet-for-octet matching performed *after* all the foregoing 
rules have been applied).

The UsernameCaseMapped profile that I point to above does all of those 
things for you, so I think it is easiest just to point to that profile 
(as draft-ietf-xmpp-6122bis now does, too). At least I think this is the 
right thing to do, based on what I understand of the requirements here. 
I admit that I might be missing something...

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 27 Nov 2014 06:03:40 +0000

> Sent: Thursday, November 27, 2014 8:55 AM
> To: Tirumaleswar Reddy (tireddy); Dave Thaler; [email-masked]
> >>>>>> and that "the method of generating this value is out of scope".
> >>>>>> Are there at least any examples of what an ID indicator might look
> like?
> >>>>>
> >>>>>> Over in the PRECIS WG, we have put a great deal of thought into
> >>>>>> the handling of internationalized strings within protocols. The
> >>>>>> PRECIS "IdentifierClass" is intended to provide the foundation
> >>>>>> for identifiers that are quite safe to use (e.g., by forbidding
> >>>>> Okay, so ID Indicator will consist only of Unicode code points
> >>>>> that conform to the "IdentifierClass" base string class defined in
> >>>>>> It maps fullwidth and halfwidth characters (common in certain
> >>>>>> East Asian languages), applies Unicode Normalization Form C (NFC),
> etc.
> >>> from draft-ietf-saslprepbis, probably the case-mapping version
> >>> instead of the case-preserving version. (Right now the spec doesn't
> >>> have both of those versions in it, but it will soon.)
> >
> > Okay, I guess it means that the PCP client will use Case-mapping rule
> https://tools.ietf.org/html/draft-ietf-precis-framework-20#section-5.2.3 for
> ID indicator comparison.
> >
> > -Tiru
> 
> Hi Tiru,
> 
> Well, not quite, because case mapping is only one small part of the problem.
> (Yes, internationalization is hard in a messy way.)
> 
> Your message inspired me to update draft-ietf-precis-saslprepbis so that it
> defines exactly what I think the PCP WG needs:
> 
> As Dave Thaler has pointed out, a "Definite" comparison algorithm provides
> a single well-defined comparison method. In the context of the work we've
> been doing in the PRECIS WG, such a comparison algorithm includes the
> following:
> 
> 1. Specification of the allowable range of Unicode characters (in PRECIS we
> have narrowed this down to two string classes: the IdentifierClass and the
> FreeformClass).
> 
> 2. Specification of rules for width mapping, so-called additional mappings
> (e.g., mapping of non-ASCII space characters to ASCII space), and case
> mapping vs. case preservation.
> 
> 3. Specification of the Unicode normalization form to be applied (typically
> NFC).
> 
> 4. Specification of how to handle strings that contain right-to-left characters.
> 
> 5. Specification of the equivalence rules for comparison purposes (typically
> octet-for-octet matching performed *after* all the foregoing rules have been
> applied).
> 
> things for you, so I think it is easiest just to point to that profile (as draft-ietf-
> xmpp-6122bis now does, too). At least I think this is the right thing to do,
> based on what I understand of the requirements here.

Thanks peter. I agree with your assessment and update to draft-ietf-precis-saslprepbis meets the PCP authentication needs. 

We will update draft- ietf-pcp-authentication with the following text:

*The ID indicator field is UTF-8 encoded Unicode code point  conforming to the "UsernameCaseMapped" profile of the PRECIS IdentifierClass. 

*PCP client validates that the ID indicator field conforms to the "UsernameCaseMapped" profile of the PRECIS IdentifierClass. PCP client enforces the rules specified in sections 3.2.2 of draft-ietf-precis-saslprepbis to map the ID indicator field. PCP client compares the resulting string with the ID indicators stored locally on the PCP client to pick the credentials for authentication. The two indicator strings are to be considered equivalent by the client if they are an exact octet-for-octet match.

-Tiru