W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > August 2007

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

From: Ed Simon <edsimon@xmlsec.com>
Date: Fri, 10 Aug 2007 15:57:08 -0400
To: <public-xmlsec-maintwg@w3.org>
Message-ID: <000a01c7db88$a3cbdbf0$6800a8c0@XMLSEC004>

Sean, I  share your opinions and had the same questions in my mind before I
sent the email.

Knowing that there are, I believe, people on this email list who have spent
many joyous man-months working with ASN.1's complexities and could be
considered ASN.1 experts, I figured that it might be good to hear from them
before I spent more time digging through dozens of pages of RFCs. There is,
after all, that difference between what the specifications say and what
real-life experience recommends. So, to those with plenty of real-life ASN.1
experience, we look forward to hearing your views.

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 10, 2007 15:24
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:
> 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:55:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:22:01 GMT