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

That looks fine except that I prefer to spell out "distinguished name"
rather than use "DName" in the bit you added to the end of my first
paragraph.

I think it would be easiest to just refer to the example given in RFC 4514
for the "Example" part.

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 Frederick Hirsch
Sent: July 30, 2007 16:56
To: ext Ed Simon
Cc: Frederick Hirsch; public-xmlsec-maintwg@w3.org
Subject: Re: Action-69: "Ed Simon to Draft warning similar to that of
section 7.2 of RFC 2253"


I believe we agreed this was for Best Practices.

Perhaps we should adopt format of The Architecture of the WWW [1]   
(and WS-Policy Guidelines [2]), e.g. Problem Statement, Best Practice
statement, Example.

With this in mind, how about the following edit:

> 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

follow the warnings of Section 5.2 of RFC 4514 regarding the reversibility
of DName encodings.

Best Practice:
> 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)

-- add example --

regards, Frederick

Frederick Hirsch
Nokia

[1] http://www.w3.org/TR/webarch/

[2] http://dev.w3.org/cvsweb/%7Echeckout%7E/2006/ws/policy/ws-policy-
guidelines.html?content-type=text/html;%20charset=utf-8



On Jul 30, 2007, at 12:08 PM, ext 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?
>
> 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".
>

Received on Monday, 30 July 2007 21:24:07 UTC