- From: merlin <merlin@baltimore.ie>
- Date: Tue, 28 Aug 2001 13:40:58 +0100
- To: "Gregor Karlinger" <gregor.karlinger@iaik.at>
- Cc: "Joseph Reagle" <reagle@w3.org>, "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Hi Gregor, I'm very strongly opposed to this. One of our goals is human readability; Jim\20Smith Research\20&\20Development is far from as readable as it should be. If we don't want human readability, we should base 64 encode the DER-encoded ASN.1 dname. Realistically, it is a _trivial_ special case; all the rest is RFC 2253. 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" That's not much of a change. Merlin r/gregor.karlinger@iaik.at/2001.08.28/13:31:23 >Merlin, > >> 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". > >To avoid all these distinctions I included the space character in the >specified range of ASCII control characters ("\00-\20"). I would prefer >to keep it as it is. > >Liebe Gruesse/Regards, >--------------------------------------------------------------- >DI Gregor Karlinger >mailto:gregor.karlinger@iaik.at >http://www.iaik.at >Phone +43 316 873 5541 >Institute for Applied Information Processing and Communications >Austria >--------------------------------------------------------------- > > ----------------------------------------------------------------------------- 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. In addition, certain Marketing collateral may be added from time to time to promote Baltimore Technologies products, services, Global e-Security or appearance at trade shows and conferences. 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 Tuesday, 28 August 2001 08:41:45 UTC