Re: Clarifying the DN text (and III)

Dear all,
See intermixed.
>
>
> "
>
> [3] only says: "... should be encoded ... " where should is written in 
> small capitalization to the additional rules
>
> I hence conclude the only normative statement in the original text is 
> that "distinguished names SHOULD be compliant with RFC2253".
>
My interpretation is that any text except those that appear in 
non-normative appendixes is normative. The difference among a SHOULD and 
a should is that the first one is given the semantics stated by RFC 
2119. This interpretation means that in fact there is not a clear 
meaning for the "should" with lower letters which should corrected if 
left there.

> ##1##
>
>
> [4]:
>>        * The |X509IssuerSerial| element, which contains an X.509
>>            issuer distinguished name/serial number pair.  The 
>> 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,
I suggest to eliminate any mention to the serial number: its encoding is 
dealt with by the fact that we have a xml schema that says that it is of 
type xsd:string. No need to say anything else. Suppress "and the serial 
number is represented as a decimal integer"

If agreed, then it is OK for me and as well the text for X509SubjectName.

> ##2##
>
> I also believe we agree on the following mentioned in [5] about the 
> DNAME escaping rules at the end of the section:
>
>> I would assume that leading spaces have been forgotten to be 
>> mentioned in the first sub point of the second bullet point.
>> This position is also supported by the examples given in 
>> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0246.html 
>> .
>
I agree that it must have been forgotten, as both RFC2253 and RFC 4514 
mention it.
>
> ##3##
>
> There is a need for a new text specifying the DNAME escaping/encoding 
> rules at the end of the section:
>
> modified version of proposal in [4]:
>> DNames (X509IssuerSerial,X509SubjectName, and KeyName) MUST be 
>> represented in accordance with RFC2253 [LDAP-DN] with the difference 
>> that they will obviously have to be encoded (UTF-8, UTF-16, UTF-32, 
>> ISO-8859-1, etc ...) the same way as the XML document and that is not 
>> limited to UTF-8.
>>  
Suggest to suppress mention within brakets of the different encoding 
mechanisms. No real value for the reader mentioning them.
> modified version of proposal in [4]:
>> 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/SHOULD/"are RECOMMENDED to" 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.
>>
>>  Note: According to RFC2253 it is valid to also escape other 
>>  characters than those mentioned in section 2.4 of RFC 2253, which is 
>> not changed by this additional requirement.
>>  
I agree with the proposal: no need to repeat what it is said in the RFC2253.
>
> I'm not strong on the MUST for control characters as I think the 
> number of use cases is more than limited.
> So a SHOULD or even "are RECOMMENDED to" will be sufficient.
OK

>
> ##4##
>
> Now the hard bit ...
>
> The remaining requirement from my point of view is if viewed very 
> strictly not RFC 2253 compliant and on top of that also confusing.
>
> Hence it should be reviewed and potentially be removed.
>>      * Escape any trailing white space by replacing "\ " with "\20".
>>   
> However I admit to see very rare cases where legacy implementations 
> will have misinterpreted the additional encoding rules as being 
> normative and the burden on receivers of signatures is minimal to 
> accept a "\20" just as being equal to a "\ " as a terminating 
> delimiter for an AttributeValue.

As I said before, I think that all the text is normative. A different 
issue is how a "should" with lower letters must be interpreted, which is 
something the specification does not say.


> I'd advocate to suggest implementations should be discouraged to 
> produce DNames being delimited by "\20", by removing this rule.
>
> Additionally some text like the following might do the trick for 
> support legacy signatures:
>>  For legacy support please note, that applications receiving 
>> signatures containing DNAMES having AttributeValues terminated by 
>> "\20" are RECOMMENDED to treat an "\20" escaped character at the end 
>> of an AttributeValue as if they were normal escaped space characters 
>> "\ " conformant to section 2.4 of RFC 2253. Do not convert "\20" to 
>> "\ " if the DNAME in question is signed.
>
This recommendation would actually maintain backwards compatibility, but 
with this change we would actually be changing something in the 
normative text (even if we do not know what "should" is meant for. On 
the other hand, it is true that there seem to be an apparent 
contradiction in the current text between the SHOULD be compliant with 
RFCV2253 and this rule, which this change would eliminate. Anyone knows 
the reason for including this new level of escaping at the end of the 
string? Maybe there was a good reason and we are missing it.

Juan Carlos.

> regards
> Konrad
>
>
> [2] http://www.w3.org/Signature/2001/04/05-xmldsig-interop.html#DNAME
> [3] http://www.w3.org/TR/xmldsig-core/#sec-X509Data
> [4] 
> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0004.html 
>
> [5] 
> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0005.html 
>
>

Received on Thursday, 7 June 2007 15:18:55 UTC