- From: Thomas Roessler <tlr@w3.org>
- Date: Tue, 29 May 2007 16:15:35 +0200
- To: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
- Cc: public-xmlsec-maintwg@w3.org
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 "\<" and "&" by "&" 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 ... "\<" --> "\<" and "&" > --> & > > ------------------------------------------------- > > 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 "\<" > "&" to keep well-formedness. > * "&" MUST be scaped to "&" 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 "\<" to "\<" and "&" 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 14:15:44 UTC