W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > May 2007

RE: Get test case for E01 / DName Issues

From: Ed Simon <edsimon@xmlsec.com>
Date: Tue, 29 May 2007 15:32:11 -0400
To: <public-xmlsec-maintwg@w3.org>
Message-ID: <000901c7a228$132b39e0$6800a8c0@XMLSEC004>

I've re-reviewed the material and think I agree with Thomas. However, I do
have a suggested rewrite of the text:

>>>
<section>
<heading>DName Encoding</heading>
<p>Except for DName AttributeValues that have a string representation,
DNames (X509IssuerSerial,X509SubjectName, and KeyName if appropriate) should
be encoded in accordance with RFC2253 [LDAP-DN]. DName AttributeValues that
have a string representation should be encoded in accordance with RFC2253
[LDAP-DN] with the following exceptions:</p>
<ul>
<li>Escape any trailing white space by replacing "\ " with "\20".</li>
<li>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.</li>
</ul>
</section>
<<<

In the above, I have removed the discussion of XML escaping and such -- that
to me is just the fundamentals of XML. Personally, I would recommend
applications use CDATA sections around DNames and MgmtData.

Ed

P.S. Also, "X509SKI element, which contains the base64 encoded" should be
"X509SKI element, which contains the base64-encoded".
_____________________________
Ed Simon <edsimon@xmlsec.com>
Principal, XMLsec Inc. 
(613) 726-9645 

Interested in XML, Web Services, or Security? Visit "http://www.xmlsec.com".


New! "Privacy Protection for E-Services" published by Idea Group (ISBN:
1-59140-914-4 for hard cover, 1-59140-915-2 for soft cover). 
Includes a chapter, by Ed Simon, on "Protecting Privacy Using XML, XACML,
and SAML".
See the Table of Contents here: "http://tinyurl.com/rukr4".

-----Original Message-----
From: public-xmlsec-maintwg-request@w3.org
[mailto:public-xmlsec-maintwg-request@w3.org] On Behalf Of Thomas Roessler
Sent: May 29, 2007 10:16
To: Konrad Lanz
Cc: public-xmlsec-maintwg@w3.org
Subject: Re: Get test case for E01 / DName Issues


I think the "closer look" is a non-issue, for several reasons:

1. I don't believe that we should have special processing rules for
   serializing a text node in this particular spot.

2. The "ambiguity" whether an implementation uses CDATA or entities
   won't matter if signed material is canonicalized, since the text
   node processing will take care of resolving this issue.

In any event, let's revisit this at the next meeting.

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








On 2007-05-24 04:05:23 +0200, Konrad Lanz wrote:
> From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
> To: public-xmlsec-maintwg@w3.org
> Date: Thu, 24 May 2007 04:05:23 +0200
> Subject: Get test case for E01 / DName Issues
> List-Id: <public-xmlsec-maintwg.w3.org>
> X-Spam-Level: 
> X-Archived-At: http://www.w3.org/mid/4654F2E3.7090009@iaik.tugraz.at
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
> 
> 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
>
Received on Tuesday, 29 May 2007 19:31:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:22:00 GMT