RE: Action-69: "Ed Simon to Draft warning similar to that of section 7.2 of RFC 2253"

It would seem to me that the last paragraph of 5.2 of RFC 4514 could be read
as recommending that the hexadecimal form should be used for ALL attributes
(whether UTF-8 or not) if one wants reversibility. On the other hand, for
attributes that are declared to be of a type limited to UTF-8, is the
hexadecimal form fully necessary? (I've used a question mark at the end of
the sentence because I'd like other opinions. For example, what happens in
an XML document, containing an XML Signature, declared as another character
encoding?)

Here is two proposed new wordings...

>>>
Section 5.2 of RFC 4514 warns that when reversibility of the distinguished
name string representation back to its initial BER or DER form is required
(as would commonly be the case in XML Signature validation), then attribute
values "SHOULD use the hexadecimal form prefixed by the number sign ('#'
U+0023) as described in the first paragraph of Section 2.4 (of RFC 4514)".
<<< 

or 

>>>
Section 5.2 of RFC 4514 warns that when reversibility of the distinguished
name string representation back to its initial BER or DER form is required
(as would commonly be the case in XML Signature validation), then attributes
which are not of a type that is UTF-8 (or a subset thereof) "SHOULD use the
hexadecimal form prefixed by the number sign ('#' U+0023) as described in
the first paragraph of Section 2.4 (of RFC 4514)".
<<< 

Obviously, if we decide for the first paragraph, then the text about
character escaping and spaces may need to change.

Ed
_____________________________
Ed Simon <edsimon@xmlsec.com>
Principal, XMLsec Inc. 
(613) 726-9645 

Interested in XML, Web Services, or Security? Visit "http://www.xmlsec.com".


New! "Privacy Protection for E-Services" published by Idea Group (ISBN:
1-59140-914-4 for hard cover, 1-59140-915-2 for soft cover). 
Includes a chapter, by Ed Simon, on "Protecting Privacy Using XML, XACML,
and SAML".
See the Table of Contents here: "http://tinyurl.com/rukr4".

-----Original Message-----
From: public-xmlsec-maintwg-request@w3.org
[mailto:public-xmlsec-maintwg-request@w3.org] On Behalf Of Sean Mullan
Sent: August 6, 2007 16:11
To: Ed Simon
Cc: public-xmlsec-maintwg@w3.org
Subject: Re: Action-69: "Ed Simon to Draft warning similar to that of
section 7.2 of RFC 2253"


Ed Simon wrote:
> Sean and Frederick,
> 
> Yes, this was intended for the Best Practices document.
> 
> Sean,
> That is interesting about PrintableString vs. UTF8String because the 
> part in quotation marks at the end is cut and pasted from RFC 4514.

I agree that RFC 4514 says that "Applications that require the
reconstruction of the DER form of the value SHOULD NOT use the string
representation of attribute syntaxes when converting a distinguished name to
the LDAP format." But your proposed wording says:

Section 5.2 of RFC 4514 warns that when reversibility of the distinguished
name string representation back to its initial BER or DER form is required
(as would commonly be the case in XML Signature validation), then attribute
values which are not of type PrintableString "SHOULD use the hexadecimal
form prefixed by the number sign ('#'
U+0023) as described in the first paragraph of Section 2.4 (of RFC 4514)".

I don't agree with that wording, specifically the part "attribute values
which are not of type PrintableString ..." RFC 4514 doesn't say that. It was
only using PrintableString as an example in the previous paragraph. 
I think it is up to us to recommend which attribute values should be encoded
as hexadecimal, and I think RFC 3280 should strongly influence our
recommendation.

Having said that, I must admit I'm a little rusty on the different formats
of directory strings. So I'm probably going to need to keep my action item
open longer while I investigate this more thoroughly.

> If others agree with your suggestion about using the OID form for 
> non-standard attribute names, we should definitely add that and 
> include an example. Would you be able to provide that example?

Yes, and there is already an example in RFC 4514. Juan Carlos, can you add a
test case to your document for this?

Thanks,
Sean


> 
> Ed
> _____________________________
> Ed Simon <edsimon@xmlsec.com>
> Principal, XMLsec Inc. 
> (613) 726-9645
> 
> Interested in XML, Web Services, or Security? Visit
"http://www.xmlsec.com".
> 
> 
> New! "Privacy Protection for E-Services" published by Idea Group (ISBN:
> 1-59140-914-4 for hard cover, 1-59140-915-2 for soft cover). 
> Includes a chapter, by Ed Simon, on "Protecting Privacy Using XML, 
> XACML, and SAML".
> See the Table of Contents here: "http://tinyurl.com/rukr4".
> 
> -----Original Message-----
> From: Sean.Mullan@Sun.COM [mailto:Sean.Mullan@Sun.COM]
> Sent: July 30, 2007 17:35
> To: Ed Simon
> Cc: public-xmlsec-maintwg@w3.org
> Subject: Re: Action-69: "Ed Simon to Draft warning similar to that of 
> section 7.2 of RFC 2253"
> 
> Ed Simon wrote:
>> With regard to Action-69 ("Ed Simon to Draft warning similar to that 
>> of section 7.2 of RFC 2253"), I propose the following text (based on 
>> RFC
>> 4514 rather than RFC 2253):
>>  
>> The XML Signature specification describes distinguished name encoding 
>> rules designed to comply with RFC 4514 and be robust within XML 
>> processing. When a distinguished name is used to identify a key, and 
>> not just to provide a human-readable string, as in Section 4 of the 
>> XML Signature specification which describes the <X509Data> element, 
>> it is important that applications incorporate the directions given in 
>> Section
>> 5.2 of RFC 4514.
>>  
>> Section 5.2 of RFC 4514 warns that when reversibility of the 
>> distinguished name string representation back to its initial BER or 
>> DER form is required (as would commonly be the case in XML Signature 
>> validation), then attribute values which are not of type 
>> PrintableString "SHOULD use the hexadecimal form prefixed by the 
>> number
> sign ('#'
>> U+0023) as described in the first paragraph of Section 2.4 (of RFC
4514)".
>> <<<
>>  
>> Comments?
> 
> I agree with Frederick that we agreed to put this in the best practices
doc.
> 
> I would also suggest changing the text above to PrintableString or 
> UTF8String. RFC 3280 requires all certificates issued after December 
> 31,
> 2003 MUST use UTF8String for DNs (except for a couple of special
> cases)
> - see section 4.1.2.4.
> 
> Also, I would suggest also adding a warning that implementations 
> should use the OID form of attribute keywords if they are not one of 
> the 9 standard short names listed in section 3 of RFC 4514. This can 
> also affect reversability.
> 
> --Sean
> 
>

Received on Friday, 10 August 2007 19:20:18 UTC