Re: E01: dname encoding rules proposal (ACTION-51)

Thomas Roessler wrote:
> I've had another look at 4.4.4, RFC 4514, and some other stuff; I
> guess some of this overlaps with material that Konrad had sent
> earlier.
> 
> Anyway...  What does 4.4.4 mean?
> 
> Basically, the references to RFC 2253 describe how to serialize a
> DName.  A DName is a set of AttributeType/AttributeValue pairs.  RFC
> 2253 (and 4514) describe how to serialize this set (this is beyond
> just converting some string of characters!).  Section 2.4 of each of
> these RFCs describes how an AttributeValue (and only that!) is
> encoded.  That's the section that is kind of reproduced in
> dsig-core.
> 
> Section 3 of both RFCs is titled "Parsing a String Back to a
> Distinguished Name", and gives a BNF grammar for a string
> representation of a Distinguished Name.  This grammar permits
> arbitrary 
> 
> 	'\' hexchar hexchar
> 
> sequences.

Note that there is an obvious bug in section 3 of RFC 2253 in that "\ "
is not permitted by the grammar: this was fixed in RFC 4514 (see
Appendix B).

> RFC 4514 further clarifies:
> 
> | While other documents may define other algorithms for converting a
> | DN from its ASN.1 structured representation to a string, all
> | algorithms MUST produce strings that adhere to the requirements of
> | Section 3.
> 
> Together, that suggests to me that there is no way to read a "\20"
> in a string representation as anything else than an escaped space
> character, even if all we reference is RFC 2253.

Good point. It does seem to be still compliant with the grammar in
section 3 of RFC 2253. Although given the bug I mentioned above, any
space that is escaped as '\ ' is illegal according to the grammar. I'd
say most implementations accept either form (I'll go check ours). And
Gregor's examples have both forms!

> 
> Further, the text in dsig-core (which has been there through a
> number of iterations of dsig-core) says:
> 
> | * The X509IssuerSerial element, which contains an X.509 issuer
> |   distinguished name/serial number pair that SHOULD be compliant
> |   with RFC2253 [LDAP-DN],
> 
> | * The X509SubjectName element, which contains an X.509 subject
> |   distinguished name that SHOULD be compliant with RFC2253
> |   [LDAP-DN], 
> 
> Note that this talks about compliance of an output string -- which
> makes most sense if you read it as a reference to section 3 of RFC
> 2253.  Yet, the text was probably meant to refer to the grammar and
> the encoding rules.
> 
> Looking back at historical records, the additional encoding rules
> were intended to address an issue raised by Gregor Karlinger [2]
> during Candidate Rec.
> 
> [3] has further discussion and explicitly clarifies that the
> proposed additional encoding rules only apply to "strings in
> DNames", *NOT* to entire DNames.
> 
> [4] includes Gregor's test cases, and clarifies that the intent of
> the additional encoding rules was to *add* to the RFC 2253 rules,
> not supersede them; note in particular the handling of leading
> whitespace in the test case.

I'm not sure his examples are correct according to the rules. Shouldn't
the first be:

"CN=\  Wolfgang \20+CN=\  Amadeus \20"

instead of

"CN=\  Wolfgang \ +CN=\  Amadeus \20"

because there is a trailing space at the end of the Wolfgang AVA String?!


> 
> Therefore, I propose we do the following:
> 
> - Change the normative references to be explicitly to RFC 2253
>   section 3, i.e., the grammar, and clarify that the RFC 2253
>   reference in the X509IssuerSerial element refers to the DName
>   only.
> 
> - Change the additional encoding rules text as follows:
> 
>      
>      	To encode a distinguished name, the rules in section 2 of
> 	RFC 2253 [REF] should be applied.  However, the string
> 	conversion rules in section 2.4 should be augmented as
> 	follows:
> 
> 	* Escape all occurrences of ASCII control characters
> 	  (Unicode range \x00 - \x1f) by replacing them with "\"
> 	  followed by a two digit hex number showing its Unicode
> 	  number.
> 	
> 	* Escape any trailing space characters by replacing them
> 	  with "\20", instead of using the escape sequence "\ ".
> 	
> 	* Since a XML document logically consists of characters, not
> 	  octets, the resulting Unicode string is finally encoded
> 	  according to the character encoding used for producing the
> 	  physical representation of the XML document.
> 
> <<<<<
> 
> Note that this demonstrates another subtle problem in the current
> text in dsig-core: The current text suggests to escape "any trailing
> whitespace." There is whitespace that is different from space
> characters, yet, the only encoding rule given is for space
> characters.
> 
> Incidentally, the WS-I basic security profile mis-reads [5] the
> additional encoding rules as encoding rules for DNames (which they
> aren't!) and makes them a MUST -- probably worth sending a flare
> over there.
> 
> 
> 1. http://www.w3.org/2001/10/xmldsig-errata
> 2. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0140.html
> 3. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001AprJun/0334.html
> 4. http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0246.html
> 5. http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html#X509IssuerSerial_Value
>

Received on Tuesday, 12 June 2007 18:23:34 UTC