[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stringprep in 3280bis


Kurt,
To be fair, the I-D does address stored strings in a couple of places, although we may have missed a reference. Please review the quotes below, along with a couple of alternatives for one update, to see if we have it right... 

Section 7.2 of this I-D includes the following text:


To accommodate
   internationalized domain names in the current structure, conforming
   implementations MUST convert internationalized domain names to the
   ASCII Compatible Encoding (ACE) format as specified in section 4 of
   RFC 3490 before storage in the dNSName field.  Specifically,
   conforming implementations MUST perform the conversion operation
   specified in section 4 of RFC 3490 as follows:

      * in step 1, the domain name SHALL be considered a "stored
      string";

 (additional steps deleted)

Sections 7.5 includes a reference to the text in 7.2.  From 7.5:


   Where the host-part (the domain of the addr-spec) contains an
   internationalized name, the domain name MUST be converted from an IDN
   to the ASCII Compatible Encoding (ACE) format as specified in section
   7.2.

   Two email addresses are considered to match if:

      1) the local-part of each name is an exact match, AND
      2) the host-part of each name matches using a case-insensitive
      ASCII comparison.
I am probably missing some nuance, but this would seem to be sufficient for sections 7.2 and 7.5.
In section 7.3, we did not specify "stored" versus "query", because it does not seem to apply. In this section 7.3, the domain component attribute contains only a single label, so we only perform the "ToASCII" operation. 


To represent a label from an IDN in the distinguished
   name, the implementation MUST perform the "ToASCII" label conversion
   specified in section 4.1 of RFC 3490.
As I said, the "ToASCII" operation doesn't seem to care about "stored" versus "query" so we didn't specify it. However, the "ToASCII" operation does require specification of two additional inputs: the AllowUnassigned flag, and the UseSTD3ASCIIRules flag. We dropped the ball here. We should have specified that the UseSTD3ASCIIRules flag should be set, and that AllowUassigned flag is *not* set. (That works out to be the same as "stored" anyway, doesn't it?) 

(1) How about the following revision to that sentence in 7.3:
To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the STD3ASCIIRules flag is set but AllowUnassigned flag is not set.
(2) If I misinterpreted the specification of "ToASCII", and we do need to specify "stored" vs. "query", we could use this alternate text:
To represent a label from an IDN in the distinguished name, the implementation MUST perform the "ToASCII" label conversion specified in section 4.1 of RFC 3490, where the string preparation is performed as a "stored" string.
Am I correct that 7.2 and 7.5 are okay? What do you think of the alternatives for 7.3? 

Thanks,

Tim

At 11:39 PM 6/21/2006 -0700, Kurt D. Zeilenga wrote:


For various values, this I-D discusses how strings are to be
prepared using various profiles of the StringPrep algorithm.
However, the I-D fails to discuss whether the strings should
be prepared as "stored" or "query" strings (see Section 4
of RFC 3490).   The I-D should be revised so as to be clear
which strings are to be treated as "stored" strings and which
are to be treated as "query" strings.

Off the cuff, I suspect the right thing to do is:
  1) requiring each prepared string in a certificate/CRL be
    treated as "stored", and
  2) prepared strings to be compared against prepared strings
  in a certificate/CRL to be treated as either "query" or "stored".
This assures that each comparison between prepared strings
involves at least one "stored" string.

-- Kurt

At 01:42 PM 6/16/2006, Stephen Kent wrote:
>Folks,
>
>Based on the latest message from David Cooper, I am initiating last call on "Internet X.509 Public Key Infrastructure, Certificate and Certificate Revocation List (CRL) Profile" (<http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt>http://ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-03.txt) 
>
>The last call will last for two weeks. In deference to the U.S. Independence Dya holiday (which means July 3rd is a holiday for many folks), all comments must be received by July 5th. 
>
>Steve