Subject: [precis] Fwd: I-D ACTION:draft-nemoto-precis-framework-implement-report-00.txt

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Jul 2012 11:30:33 -0600

Of interest...

-------- Original Message --------
Subject: I-D ACTION:draft-nemoto-precis-framework-implement-report-00.txt
Date: Thu, 05 Jul 2012 08:11:38 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A new Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title         : precis framework implementation report
    Author(s)     : T. NEMOTO, et al
    Filename      : draft-nemoto-precis-framework-implement-report
    Pages         : 9
    Date          : July 5, 2012

   This document reports implementation experience of precis framework
   [I-D.ietf-precis-framework] for SASLprepbis
   [I-D.melnikov-precis-saslprepbis] and findings from the experience.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nemoto-precis-framework-implement-report-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Takahiro Nemoto <[email-masked]>
Date: Fri, 6 Jul 2012 13:14:16 +0900

Dear Peter-san and all,

Thank you for introducing our I-D. Please read and 
give your comments/suggestions.

Regards,

Nemo

--
Takahiro Nemoto
[email-masked]

On 2012/07/06, at 2:30, Peter Saint-Andre wrote:

> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Jul 2012 15:19:32 -0600

On 7/5/12 10:14 PM, Takahiro Nemoto wrote:
> Dear Peter-san and all,
> 
> Thank you for introducing our I-D. Please read and give your
> comments/suggestions.

First, thank you for working on this document.

I agree with you that "the file describing derived property value
table for precis should be generated". It is also good to know that
you have worked on an implementation that generates the tables. I am
also working on an implementation (unfortunately I did not have time
to finish it before IETF 84, but I plan to do that in August) and
would like to "compare notes" with you. I recognize that the tables in
draft-ietf-precis-framework are quite likely incorrect in some places
since I created them by hand, so I will work to make more accurate
tables next month.

You mention the need to do string validity checking, for example to
make sure that string length is non-zero. Do you think that is a
PRECIS check or a check at the application layer? I've always thought
this is something that the application would do, not PRECIS.

As to special mappings like "Map to SPACE" and "Map to Nothing", it
seems to me that in a post-stringprep system we can handle those by
more carefully defining the string classes.

You make a good point about the order of processing (normalization
then validity in IDNA2008 vs. validity then normalization in
SASLprep-bis). It does seem preferable to have a consistent order.
Let's make sure we have discussion about this at the meeting two weeks
from now.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Takahiro Nemoto <[email-masked]>
Date: Wed, 18 Jul 2012 19:24:29 +0900

Thank you so much for the reviews.

> since I created them by hand, so I will work to make more accurate

I'd like to compare notes with you too, and I'm happy if I can co-work with you :-)

> this is something that the application would do, not PRECIS.

I think that maybe some checks are included at PRECIS.
I think if PRECIS does not define any checks in the protocol 
and an application developer forget to implement some checks 
in an application, this application may cause vulnerabilities.

> more carefully defining the string classes.

Sorry, but I don't get it. What does a post-stringprep system mean?

> Let's make sure we have discussion about this at the meeting two weeks

Yes, we do. I think that It is preferable to have a consistent order.
Different results from the order of processing can now only be found in Hangul.
If you know any examples, please let us know.

Nemo

--
Takahiro Nemoto
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 18 Jul 2012 09:12:28 -0600

On 7/18/12 4:24 AM, Takahiro Nemoto wrote:
>> I agree with you that "the file describing derived property
>> value table for precis should be generated". It is also good to
>> know that you have worked on an implementation that generates the
>> tables. I am also working on an implementation (unfortunately I
>> did not have time to finish it before IETF 84, but I plan to do
>> that in August) and would like to "compare notes" with you. I
>> recognize that the tables in draft-ietf-precis-framework are
>> quite likely incorrect in some places since I created them by
>> hand, so I will work to make more accurate tables next month.
> 

Yes, let's chat about that off-list.

>> You mention the need to do string validity checking, for example
>> to make sure that string length is non-zero. Do you think that is
>> a PRECIS check or a check at the application layer? I've always
>> thought this is something that the application would do, not
>> PRECIS.
> 
> I think that maybe some checks are included at PRECIS. I think if
> PRECIS does not define any checks in the protocol and an
> application developer forget to implement some checks in an
> application, this application may cause vulnerabilities.

So we can advise applications to prohibit zero-length strings in
identifiers. :) It seems to me that PRECIS only tells you how to
perform all the i18n handling, and doesn't define application-level
restrictions such as string length.

>> As to special mappings like "Map to SPACE" and "Map to Nothing",
>> it seems to me that in a post-stringprep system we can handle
>> those by more carefully defining the string classes.
> 

A system that uses PRECIS.

Because PRECIS uses an inclusion model (only characters / code points
/ codepoint classes that are explicitly allowed can be included in a
conformant string), I don't see any reason to have these "mapped to
space" or "mapped to nothing" rules in PRECIS-based systems. For
example, just allow space (U+0020) but not other space characters.

>> You make a good point about the order of processing
>> (normalization then validity in IDNA2008 vs. validity then
>> normalization in SASLprep-bis). It does seem preferable to have a
>> consistent order. Let's make sure we have discussion about this
>> at the meeting two weeks from now.
> 
> Yes, we do. I think that It is preferable to have a consistent
> order. Different results from the order of processing can now only
> be found in Hangul. If you know any examples, please let us know.

OK, I will add this to our list of open issues for the framework
document and include it in our discussion at IETF 84.

Peter

---

From: Takahiro Nemoto <[email-masked]>
Date: Fri, 27 Jul 2012 22:50:54 +0900

Thank you for your comments.

> example, just allow space (U+0020) but not other space characters.

"mapped to nothing" may generate zero-length strings and it may 
cause vulnerabilities for applications. Therefore, I think I just want to 
give application developers a heads-up about this in the protocol or 
the security sonsiderations.
But, I don't necessarily want to define application-level restrictions in 
the protocol.

So I would like to hear more member's comments about this.

> document and include it in our discussion at IETF 84.

nemo

--
Takahiro Nemoto
[email-masked]