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

Ed Simon wrote:
> 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?)

I agree. I am leaning towards something like your second wording because
I don't like the idea of using hexadecimal encoding for all values. It
seems to me there is another issue though:

If the hexadecimal form is not used, does the loss of the Attribute
String's OID cause problems when using the String to match DNs in
encoded certificates and CRLs?

For example, if you had two Attribute Values that are UTF-8 compatible
(UTF8String and PrintableString), and encoded their values as a String
instead of hexadecimal, then the receiver won't know what type of String
they are when you match it against the DN in a Certificate or CRL. Is
this a problem? Can you always match them as Strings, rather than their
DER encoded form? I'm not sure, I wanted to think about this some more.

RFC 4517 (section 3.3.6 and 3.3.9) and 4518 discuss the String formats
and how to match them. I think the key to my questions are in these RFCs
but I haven't found enough time to carefully read through them yet. I
think the answer is that maybe only TeletexStrings are a problem and
should be encoded as hexadecimal. Perhaps if you have some time you can
let me know what you think.

--Sean

> 
> 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:24:26 UTC