E01: dname encoding rules proposal (ACTION-51)

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.

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.

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.

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

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Tuesday, 12 June 2007 16:05:43 UTC