Re: XMLDSIG erratum

Hi Gregor,

In theory, my intention is probably what you quoted.
In practice, my intention is (I think) the following
(single quotes are just serving to delinate the dname):

. no quoting values within dnames
INVALID: 'O="Foo, Inc."'
VALID: 'O=Foo\, Inc.'

. escape just trailing dname space
INVALID: 'CN=Jim\ +CN=Bob\ '
VALID: 'CN=Jim\ +CN=Bob\20'

NOT RECOMMENDED: 'CN=\20Bob\20\20'
RECOMMENDED: 'CN=\ Bob\ \20'
  - could be strict and make this INVALID/VALID

. don't UTF-8 encode dnames
INVALID: 'CN=Mädb'
VALID: 'CN=Mädb'
  -- serialized with ISO 8859-1, M a-umlaut d b

. escape control characters
INVALID: 'CN=AB' -- that's an escape character
VALID: 'CN=A\1bB'

This is probably just a subset of the cases and I've not
verified any of them, just typed them in by hand, but broadly
those were (I think) my intentions. And I think you're right;
our intentions are not necessarily clearly reflected in the
spec.

Of course, the fact that the encoding is only mandated with
"SHOULD" means that people may do things any way they want.

Merlin

r/gregor.karlinger@cio.gv.at/2002.03.17/22:01:12
>Joseph and Merlin,
>
>once again our rules for encoding strings in DNames keep me busy ...
>I digged a bit in the list archive because I wanted to find the rea-
>son why the text in the REC is as it is. 
>
>I found the following messages from merlin [1], [2], which clearly 
>reflects the *intention* of our strings-in-DNames rules:
>
>------------------------------------------------------------------------
>----
>
><merlin1>
>  4.4.4 The X509Data Element (dname encoding)
>
>  I'd possibly suggest that instead of "compliant with RFC2253", we
>  use the text "compliant with the subset of RFC2253 described below"
>  or somesuch, because RFC2253 allows encodings that are not permitted
>  by the text that we have.
>
>  Is it intended that space be considered an ASCII control character;
>  if not, I'd suggest the text "\00-\1f inclusive".
>
>  In this case, leading and trailing ' ' should be escaped. If we want
>  to allow leading and trailing whitespace to be trimmed from dname
>  text nodes then we also need to state that a "\ " occuring at the
>  end of a dname must be replaced by "\20".
></merlin1>
>
><merlin2>
>  Ignoring UTF-8 encoding, the current wording is:
>
>  RFC 2253 -> replace "\ " with "\20" -> replace 0x00-0x20 with "\xx"
>
>  My suggested wording is:
>
>  RFC 2253 -> replace 0x00-0x1f with "\xx" -> replacing trailing "\ "
>  with "\20"
></merlin2>
>
>------------------------------------------------------------------------
>----
>
>If this is really the intention of our rules, the text in the REC is
>totally
>misleading and urgently needs to be fixed via the errata document, for 
>example:
>
>  (1) The text in the REC does not state that we basically use the
>encoding
>      rules for strings as specified in RFC2253, but additionally apply
>the
>      execptions stated in the text. Rather the text in the REC and in
>the 
>      errata document respecively states:
> 
>        "the encoding of the distinguished name SHOULD be compliant with
>
>         the DNAME encoding rules at the end of this section." 
>
>      and
> 
>        "DNames ... should be encoded in accordance with RFC2253
>[LDAP-DN] 
>         except for the encoding of string values within a DName: ..." 
>
>  (2) The fourth bullet in the rec text states:
>        "Escape any trailing white space by replacing "\ " with "\20"."
>      According to to <merlin1> this should rather read:
>        "Escape a "\ " at the end of the string with "\20".
>
>------------------------------------------------------------------------
>----
>
>Merlin, could you please tell me your view on the intention of the REC 
>encoding rules?
>
>Regards, Gregor
>
>[1]
>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JulSep/0181.htm
>l
>[2]
>http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JulSep/0183.htm
>l
>


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Monday, 18 March 2002 18:03:18 UTC