Re: Action 43: to produce example for breakage due to current E01 language

Hi Sean,

Sean Mullan wrote:
> Konrad Lanz wrote:
>> [...]
>> So with respect to "\<" and "&" in a DName string representation, 
>> this action is discharged ... and this is a non-issue also from my 
>> perspective.
>
> So are we recommending that KeyInfo should always be signed if it 
> contains DNames? 
No, just in case it is signed it shall be canonicalized and then it will 
not matter how the string was represented wrt. "\<" and "&".
> I'm not sure I understand the outcome of this discussion.
Well, as far as I am concerned, I believe it does not matter if "\<" and 
"&" are represented by their  entities "\&lt;" and "&amp;" or live in a 
CDATA section representing the DNAME in their serialized form as the 
string value returned by some API (DOM, SAX) should not be affected. 
Also if the canonicalized form is signed then CDATA sections will be 
converted to text using entities.

>>>     * Escape any trailing white space by replacing "\ " with "\20".
>>>
>> [...] doubt that this is RFC2253 compliant. RFC 2253 explicitly 
>> mentions that the last space in an Attribute value will have to be 
>> escaped using "\ " and not "\20" [...]
>
> Anyone know how to find Gregor as he may be the only one who knows?
I asked a colleague still in contact with him and we'll see what we can 
find out.
>> [...] mention that 
>> http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME 
>> refers to the link above and even talks about "The following example 
>> set contains test vectors for the OPTIONAL DNAME encoding" which 
>> clearly indicates to me that the so called "DNAME encoding rules at 
>> the end of section 4.4.4" are optional and non normative.
>
> Good observation.
>
>> [...] A quick proposal to serve as a basis for further discussion:
>>> DNames (X509IssuerSerial,X509SubjectName, and KeyName) MUST be 
>>> represented in accordance with RFC2253 [LDAP-DN] with the difference 
>>> that they will obviously have to have the same encoding (UTF-8, 
>>> UTF-16, UTF-32, ISO-8859-1, etc ...) as the XML document and are not 
>>> limited to UTF-8.
>>> The AttributeValues within a DName are escaped according to the 
>>> rules laid out in RFC2253 with the additional requirement that 
>>> esacping of control characters MUST be performed as follows:
>>>
>>>     * Escape all occurrences of control characters (Unicode range x00
>>>       - x1f) by replacing them with "\" followed by a two digit hex
>>>       number showing its Unicode number.
>
> Why a MUST? Why is it so important to escape control characters? It is 
> probably obvious to others but I just want to understand the rationale 
> more. It would be nice to be able to support the default RFC 2253 
> algorithm without *requiring* any additional processing.

Well for the moment I simply assumed each character plays a role, but it 
may be worth having a closer look at for example

http://tools.ietf.org/html/rfc4514 :
> Comparison of DNs for equality is to be performed in accordance
>    with the distinguishedNameMatch matching rule [RFC4517 <http://tools.ietf.org/html/rfc4517>].
and RFC 4517 section  4.2.15. distinguishedNameMatch 
(http://tools.ietf.org/html/rfc4517#section-4.2.15) :
> Two AVAs with the same
>    attribute type are the same if their values are equal according to
>    the equality matching rule of the attribute type.
 From here however it looks like it becomes complicated ... so I 
preferred to assume everything matters ...

regards

Konrad

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