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 Monday, 6 August 2007 20:13:40 UTC