- 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