Get test case for E01 / DName Issues

Dear all,

having taken a closer look at section 4.4.4 
<http://www.w3.org/2007/xmlsec/Drafts/xmldsig-core/#sec-X509Data> and at 
E01 <http://www.w3.org/2001/10/xmldsig-errata#E01> as well as Gregors 
Mail 
<http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0112.html> 
I think 4.4.4 actually need more attention than we thought ...

-------------------------------------------------


        4.4.4 The |X509Data| Element

Identifier
    |Type="http://www.w3.org/2000/09/xmldsig#X509Data
    <http://www.w3.org/2000/09/xmldsig#SPKIData>| "
    (this can be used within a |RetrievalMethod| or |Reference| element
    to identify the referent's type) 

An |X509Data| element within |KeyInfo| contains one or more identifiers 
of keys or X509 certificates (or certificates' identifiers or a 
revocation list). The content of |X509Data| is:

   1. At least one element, from the following set of element types; any
      of these may appear together or more than once iff (if and only
      if) each instance describes or is related to the same certificate:
   2.
          * The |X509IssuerSerial| element, which contains an X.509
            issuer distinguished name/serial number pair.  The X.509
            issuer 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,
          * The |X509SKI| element, which contains the base64 encoded
            plain (i.e. non-DER-encoded) value of a X509 V.3
            SubjectKeyIdentifier extension.
          * The |X509Certificate| element, which contains a
            base64-encoded [X509v3
            <http://www.w3.org/TR/xmldsig-core/#ref-X509v3>]
            certificate, and
          * Elements from an external namespace which
            accompanies/complements any of the elements above.
          * The |X509CRL| element, which contains a base64-encoded
            certificate revocation list (CRL) [X509v3
            <http://www.w3.org/TR/xmldsig-core/#ref-X509v3>].

-------------------------------------------------

Please consider now the following DName as a challenging test case

CN: Rick + Fred, III
O: ÄËÏÖÜ \ Rick & Fred <devices>;
OU: #ING
C: AT

now let's make it RFC2253 compliant

CN=Rick \+ Fred\, III, O=ÄËÏÖÜ \\ Rick & Fred \<devices\>\;, OU=\#ING, C=AT

and now lets put it into the X509IssuerName

<X509IssuerName>CN=Rick \+ Fred\, III, O=ÄËÏÖÜ \\ Rick & Fred \<devices\>\;, OU=\#ING, C=AT</X509IssuerName>

and a document contining this X509IssuerName is not well formed any more 
... --> Which is really bad

So we can either put it into a CDATA section or escape the "<" by 
"\&lt;" and "&" by "&amp;" showing that there is actually a need to 
change the so called "DNAME encoding rules at the end of this section".

We'll also have to require applications to do the inverse operation ... 
"\&lt;" --> "\<" and "&amp;"  --> &

-------------------------------------------------

Strings in DNames (appearing in X509IssuerName, |X509SubjectName|, and 
|KeyName| if approriate) should be encoded as follows:

    * Consider the string as consisting of Unicode characters.
    * Escape occurrences of the following special characters by
      prefixing it with the "\" character:
          o a "#" character occurring at the beginning of the string
          o one of the characters ",", "+", """, "\", ">", ";" or "<".
            The latter "<" also MUST be effectively escaped to "\&lt;"
            "&amp;" to keep well-formedness.
    * "&" MUST be scaped to "&amp;" to keep well-formedness.
    * 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 white space by replacing "\ " with "\20".
    * 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.

As soon as one of these DNames is used (i.e. passed to another software 
component)
the application MUST convert "\&lt;" to  "\<" and "&amp;"  to "&" .
-------------------------------------------------

For future work we should also note there is a successor to RFC 2253. It 
is RFC 4515 and this one should be referred to in future versions.
http://tools.ietf.org/html/rfc2253
http://tools.ietf.org/html/rfc4514


regards
Konrad

P.S: I think, most implementations based on DOM should actually behave 
in this manner already.

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