Re: Poll on Exclusive Canonicalization

Hi Phil,

From:  Phillip Hallam-Baker <pbaker@verisign.com>
Message-ID:  <2F3EC696EAEED311BB2D009027C3F4F40154C997@vhqpostal.verisign.com>
To:  w3c-ietf-xmldsig@w3.org
Date:  Mon, 18 Jun 2001 07:20:32 -0700

>...
>
>The ambiguity in what namespaces should be included in the scope of the C14N
>is the main cause of interop issues with XKMS - and I would guess by
>extension in any SOAP/XML Protocol application.

Right. As soon as you do the simplest thing, like wrapping one level
of element around a signature or around an element with a signature as
a descendent or around an element signed by a detached signature or
removing one level of element around a signature or around an element
with a signature or xml signed by a detached signature as a
descendent, interoperability breaks, if namespaces are involved.

>Rather than mess with the 'mandatory' status we should recognize that the
>specification cannot mandate support for a specific canonicalization
>algorithm and it is entirely wrong and unjustified to do so. 

Why? Wouldn't your argument apply equally well to the DER
canonicalization of ASN.1? It's really a serialization of ASN.1 just
like "CanonicalXML" is a serialization of XML.  Was it a mistake to
standardize DER? Should interoperability of ASN.1 encoded signatures
have been entirely an application/protocol responsibility so that for
each protocol you would have had to figure out a
canonicalization/serialization?

DER doesn't solve all problems. For example, it does not canonicalize
data types it does not know about, like HTML colours. Neither will an
"exclusive" XML canonicalization solve all problems. But if it works
for 90%+, as I think as simple tweak to the current C14N can, then it
will be a great help to those who want to use XMLDSIG.

>The proposed C14N does not meet the requirements of signing SOAP or XML
>Protocol messages. Any spec to support that application will inevitably
>specify that another C14N algorithm is required. As currently specified the
>C14N algorithm does not satisfy the requirement that nodes be signable
>individually and independently.

Right, but even a simple exclusive C14N will.

>Counter proposal:
>
>1) Demote the requirement for the existing C14N from MUST to SHOULD

If canonicalization is required, as it clearly is for SignedInfo for
XML applications, if there is no required C14N, there is no
interoperability. In that case, I would question whether we have
something that would qualify as an IETF standard anymore. Certainly
you no longer have anything where you can expect implementations to
interoperate.

>2) Insert a forward looking 'SHOULD support' for exclusive C14N

Forward looking requirement have process problems.

>3) Develop spec for alternative C14N 

Seems like this is going to happen one way or the other.

>4) When Signing XML Protocol messages is written it will specify
>   the alg that is most appropriate as a MUST.
>
>XML Signature is not a complete specification, it is a component. MUST
>implement for interoperability does not make as much sense at the component
>level as at the system level.

The current XMLDSIG is a complete specification that works fine for
static documents as our interoperability tests prove.  IETF experience
is that interoperability testing is critical.  I really don't think it is
that big a change to add exclusive canonicalization and make it effective
and interoperable for 90%+ of protocol cases.

Donald

>		Phill
>
>Phillip Hallam-Baker FBCS C.Eng.
>Principal Scientist
>VeriSign Inc.
>pbaker@verisign.com
>781 245 6996 x227
>
>
>> -----Original Message-----
>> From: Thomas Maslen [mailto:maslen@dstc.edu.au]
>> Sent: Friday, June 15, 2001 3:47 AM
>> To: w3c-ietf-xmldsig@w3.org
>> Subject: Re: Poll on Exclusive Canonicalization 
>> 
>> 
>> > With respect to the issue of excluding ancestor context 
>> from the canonical 
>> > form of a signature[1], the WG should pursue option:
>> > 
>> > 1. Specify the exclusive canonicalization as part of the 
>> non-normative (nor 
>> >    required to implement) dsig-more specification [2].
>> >
>> > 2. Specify the exclusive canonicalization as part of the normative 
>> >    xmldsig-core  as proposed in [3] (but with the URIs of 
>> [4]) as [REQUIRED, 
>> >    RECOMMENDED, OPTIONAL]. (This option requires 
>> interoperable implementation 
>> >    of this feature before xmldsig advances.)
>> 
>> Speaking for the JCSI gang at DSTC:
>> 
>> We believe that a significant percentage of candidate xmldsig 
>> applications 
>> suffer from the c14n variable-context issue.  Given this, we 
>> believe that
>> for xmldsig to be usable and interoperable, it is worthwhile 
>> for xmldsig to 
>> specify an interoperable c14n approach that resolves this 
>> issue, despite the
>> effect of this on the standardization schedule.
>> 
>> In other words, our preference is for option 2.  
>> 
>> Also, in the interests of interoperability, RECOMMENDED (or 
>> ideally REQUIRED)
>> would be preferable to OPTIONAL.
>> 
>> Thomas Maslen
>> DSTC
>> 
>
>
>------_=_NextPart_000_01C0F801.D5189E30
>Content-Type: application/octet-stream;
>	name="Phillip Hallam-Baker (E-mail).vcf"
>Content-Disposition: attachment;
>	filename="Phillip Hallam-Baker (E-mail).vcf"
>
>BEGIN:VCARD
>VERSION:2.1
>N:Hallam-Baker;Phillip
>FN:Phillip Hallam-Baker (E-mail)
>ORG:VeriSign
>TITLE:Principal Consultant
>TEL;WORK;VOICE:(781) 245-6996 x227
>EMAIL;PREF;INTERNET:hallam@verisign.com
>REV:20010214T163732Z
>END:VCARD
>
>------_=_NextPart_000_01C0F801.D5189E30--
>

Received on Wednesday, 20 June 2001 00:27:18 UTC