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/0021
>> .html
>>
>>
>> and that was commented by Ed in
>> http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0024
>> .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 08:45:12 UTC