W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > June 2007

E01: dname encoding rules proposal (ACTION-51)

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 12 Jun 2007 18:05:28 +0200
To: public-xmlsec-maintwg@w3.org
Message-ID: <20070612160528.GT2823@raktajino.does-not-exist.org>

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

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

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

	'\' hexchar hexchar


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

- 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

	* 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
	* 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

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:42 UTC