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

Let me try to summarize today's discussion on this:

- Rich, Konrad and a bunch of others agreed that the \20 rule is
  actually unnecessary and probably not implemented in practice.

- Greg and I argued that that might very well be a change that was
  desirable, but not one we should be doing right now.

Part of the issue as I see it is that the DNAME encoding rules are
actually referenced with a MUST from the WS-I BSP.  We don't know
whether that's an oversight on their side or actually indicates that
there are implementations of these rules that we don't know of.

Therefore, I propose that we adopt the text as currently in the
Editor's Draft, with a possible change of reference to 4514, thereby
(a) leaving the conformance model as dodgy as it is right now, and
(b) try to clean up the technical content to make it somewhat more
understandable.

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






On 2007-06-12 18:05:28 +0200, Thomas Roessler wrote:
> From: Thomas Roessler <tlr@w3.org>
> To: public-xmlsec-maintwg@w3.org
> Date: Tue, 12 Jun 2007 18:05:28 +0200
> Subject: E01: dname encoding rules proposal (ACTION-51)
> X-Spam-Level: 
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> 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, 19 June 2007 14:16:52 UTC