Updated Editor's Draft for DSIG-Core (Re: E01: dname encoding rules proposal (ACTION-51))

I've produced an updated editor's draft that includes these proposed
changes. Note that change marks are against the original REC, not
against intermediate versions.

  http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-X509Data
  XML-Signature Syntax and Processing
  Editor's Draft $Date: 2007/06/12 17:26:35 $

Regards,
-- 
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, 12 June 2007 17:32:19 UTC