RE: Additional issue on RFC 2253 usage in relation with XMLSig: On the capability of the RFC2253 "CN=Sam"encoding form for identifying a Certificate.

Hi Juan Carlos,

In writing my prior note, I was agreeing with Konrad's view (see his note
way below) and adding some thoughts. I agree that RFC 4514 enables
reversibility but I want both reversibility and full XML compatibility so as
to avoid the need for other XML-based standards to create their own DN
encoding rules (as we are doing). 

I would like to revise the phrase I used about "not necessarily a canonical
form". Rather, I would indeed like an XML-compatible form that is canonical
from an information set perspective and so can be easily fully canonicalized
by basic XML Canonicalization. The form should also be canonical in light of
DN matching rules such as http://tools.ietf.org/rfc/rfc4517.txt
as well as any fixups for short vs. full names, alphabetical ordering, etc.

Here's an idea of what I'm getting at:
<ds:KeyName>
<dname xmlns="http://ietf.org/rfcXXXX">
<attribute>+
<type></value>
<value></value>
</attribute>
</dname>
</ds:KeyName>

In short, I want a DN representation that is unambiguous, canonicalizable,
and robust from an XML-processing perspective. (FYI, as a personal general
rule, I tned to regard potentially relevent leading or trailing relevant
white space as a red flag when it comes XML processing robustness and
security.)

Ed

-----Original Message-----
From: public-xmlsec-maintwg-request@w3.org
[mailto:public-xmlsec-maintwg-request@w3.org] On Behalf Of Juan Carlos
Cruellas
Sent: June 19, 2007 04:45
To: Ed Simon
Cc: public-xmlsec-maintwg@w3.org
Subject: Re: Additional issue on RFC 2253 usage in relation with XMLSig: On
the capability of the RFC2253 "CN=Sam"encoding form for identifying a
Certificate.


RFC 2253 and 4514 define two ways of representing attributes in the DN:
the pair short-name=value's string
the pair dotted-decimal encoding of the OID of the attribute = #hexadecimal
encoding of the octets of the BER encoding off the X.500 AttributeValue.

The second alternative seems to me to have all the information required for
reversibility .
 
The issue is that both seem to mandate that the first alternative has to be
used when the attribute has a published short name, whereas the second one
is for the rest of the attributes.

Juan Carlos.
Ed Simon escribió:
> Perhaps it would be best if the IETF define a means of representing 
> DNames in XML-compatible, DER-reversible format (not necessarily a 
> string, and not necessarily a canonical form) that could be put into 
> the XML Signature <KeyInfo> element.
>
> In the next version of XML Signature, if it continues to own the 
> <KeyInfo> element, then DName supporting elements could be defined as
xs:any content.
>
> 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 Konrad Lanz
> Sent: June 18, 2007 16:19
> To: public-xmlsec-maintwg@w3.org
> Subject: Re: Additional issue on RFC 2253 usage in relation with 
> XMLSig: On the capability of the RFC2253 "CN=Sam"encoding form for 
> identifying a Certificate.
>
> Dear all,
>
> I do not think that XMLDSig is the right place to perform DNAME 
> constraining, canonicalization or comparison.
> Usually RFC 2253/4514 implementations will parse two string 
> representations and rather use means as specified in RFC 4517 section 
> 4 to compare two values.
>
> However I would agree giving input to the IETF as these specifications 
> are located in their premises. Such input could essentially ask for a 
> canonical string representation for DNAMEs.
>
> That would be really nice and such a DNAME comparison could then be 
> reduced to a simple string comparison. ;-)
>
> Konrad
>
> Juan Carlos Cruellas wrote:
>   
>> Dear all,
>>
>> I understood in our last conference call that Frederick suggested to 
>> summarize the issues related to the RFC 2253 stuff within XMLSig.
>>
>> In addition to the RFC 2253 encoding stuff that we have been 
>> discussing in a separated thread, and which has been summarized by 
>> Thomas, who has raised a proposal last week, I would like to remind 
>> an issue that I raised in
>> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/002
>> 1
>> .html
>>
>>
>> and that was commented by Ed in
>> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/002
>> 4
>> .html
>>
>>
>> This issue deals with the fact that both RFC 2253 and RFC 4514 make 
>> it clear that the String representation using short names and string 
>> values for for representing DNs may put problems when trying to 
>> identifying without ambiguity the corresponding certificate...
>>
>> Could we deal with this, once we have agreed on the encoding issue?
>>
>> Regards
>>
>> Juan Carlos.
>>
>>     
>
>
> --
> Konrad Lanz, IAIK/SIC - Graz University of Technology Inffeldgasse 
> 16a, 8010 Graz, Austria
> Tel: +43 316 873 5547
> Fax: +43 316 873 5520
> https://www.iaik.tugraz.at/aboutus/people/lanz
> http://jce.iaik.tugraz.at
>
> Certificate chain (including the EuroPKI root certificate):
> https://europki.iaik.at/ca/europki-at/cert_download.htm
>
>
>

Received on Tuesday, 19 June 2007 14:57:54 UTC