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.

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 Monday, 18 June 2007 20:42:33 UTC