Re: Clarifying the DN text

Dear Ed, Sean and others,

Ed Simon wrote:
> [...] what was originally meant. [...]
>   

[2] says: "The following example set contains test vectors for the 
OPTIONAL DNAME encoding"

[3] says: "

    * The |X509IssuerSerial| element, which contains an X.509 issuer
      distinguished name/serial number pair that SHOULD be compliant
      with RFC2253 [LDAP-DN
      <http://www.w3.org/TR/xmldsig-core/#ref-LDAP-DN>],
    * The |X509SubjectName| element, which contains an X.509 subject
      distinguished name that SHOULD be compliant with RFC2253 [LDAP-DN
      <http://www.w3.org/TR/xmldsig-core/#ref-LDAP-DN>],

"

[3] only says: "... should be encoded ... " where should is written in 
small capitalization to the additional rules

I hence conclude the only normative statement in the original text is 
that "distinguished names SHOULD be compliant with RFC2253".

Ed Simon wrote:
> [...] "how it should be written" [...]
>   

So now let's first see if we agree on the easy bits:

##1##

As I wrote in [4] already
The text says:

  "At least one element, from the following ... "

So the bullet points will still have to enumerate the the choice of 
elements within the content of |X509Data| which is not the case in the 
current red line document ... and will need to be changed to something like the following:

[4]:
>        * The |X509IssuerSerial| element, which contains an X.509
>            issuer distinguished name/serial number pair.  The distinguished
>            name SHOULD be compliant with the DNAME
>            encoding rules at the end of this section and the serial
>            number is represented as a decimal integer,
>         * The |X509SubjectName| element, which contains an X.509
>            subject distinguished name that SHOULD be compliant with the
>            DNAME encoding rules at the end of this section,

##2##

I also believe we agree on the following mentioned in [5] about the 
DNAME escaping rules at the end of the section:

> I would assume that leading spaces have been forgotten to be mentioned 
> in the first sub point of the second bullet point.
> This position is also supported by the examples given in 
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0246.html .


Sean wrote:

> I agree, it seems to have been a mistake.

##3##

There is a need for a new text specifying the DNAME escaping/encoding 
rules at the end of the section:

modified version of proposal in [4]:
> DNames (X509IssuerSerial,X509SubjectName, and KeyName) MUST be 
> represented in accordance with RFC2253 [LDAP-DN] with the difference 
> that they will obviously have to be encoded (UTF-8, 
> UTF-16, UTF-32, ISO-8859-1, etc ...) the same way as the XML document and that is not 
> limited to UTF-8.
>   

modified version of proposal in [4]:
> The AttributeValues within a DName are escaped according to the rules 
> laid out in RFC2253 with the additional requirement that esacping of 
> control characters MUST/SHOULD/"are RECOMMENDED to" be performed as follows:
>
>      * Escape all occurrences of control characters (Unicode range x00
>        - x1f) by replacing them with "\" followed by a two digit hex
>        number showing its Unicode number.
>
>  Note: According to RFC2253 it is valid to also escape other 
>  characters than those mentioned in section 2.4 of RFC 2253, which is not changed by this additional requirement.
>   

I'm not strong on the MUST for control characters as I think the number 
of use cases is more than limited.
So a SHOULD or even "are RECOMMENDED to" will be sufficient.

##4##

Now the hard bit ...

The remaining requirement from my point of view is if viewed very 
strictly not RFC 2253 compliant and on top of that also confusing.

Hence it should be reviewed and potentially be removed.
>      * Escape any trailing white space by replacing "\ " with "\20".
>   
However I admit to see very rare cases where legacy implementations will 
have misinterpreted the additional encoding rules as being normative and 
the burden on receivers of signatures is minimal to accept a "\20" just 
as being equal to a "\ " as a terminating delimiter for an AttributeValue.

I'd advocate to suggest implementations should be discouraged to produce 
DNames being delimited by "\20", by removing this rule.

Additionally some text like the following might do the trick for support 
legacy signatures:
>  For legacy support please note, that applications receiving signatures containing DNAMES having AttributeValues terminated by "\20" 
> are RECOMMENDED to treat an "\20" escaped character at the end of an AttributeValue as if they were normal escaped space characters "\ " conformant to section 2.4 of RFC 2253. Do not convert "\20" to "\ " if the DNAME in question is signed.

regards
Konrad


[2] http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME
[3] http://www.w3.org/TR/xmldsig-core/#sec-X509Data
[4] 
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0004.html
[5] 
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0005.html

-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
https://www.iaik.tugraz.at/aboutus/people/lanz
http://jce.iaik.tugraz.at

Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm