RE: c14n text

Fine with me, I'd also prefer to have the element always present, but wasn't 
sure what the intent of "default" was.  I also agree with Don's suggestion.

Dave

> -----Original Message-----
> From: reagle [mailto:reagle@w3.org]
> Sent: Tuesday, May 02, 2000 3:18 PM
> To: David.Solo; dee3; lde008
> Cc: reagle; w3c-ietf-xmldsig
> Subject: Re: c14n text
> 
> 
> Ok, I took your text, added Don's suggestion, and tweaked it 
> to read as
> stated below. My only concern with the text stated below is 
> that I would
> ALWAYS like this element to be present even if we REQUIRE 
> Canonical XML.
> (Just like SignatureMethod). My preference has been to 
> include syntax where
> (potentially) varied semantics are being communicated. For 
> instance, making
> a semantic always base64 merits removing elements and attributes. But
> otherwise for algorithms that we require, we haven't been setting the
> default to that required algorithm. I think this is good because it's
> explicit, less-confusing, and mitigates some fuzzy concerns I 
> have about the
> need to migrate to other algorithms in the future.
> 
> Do you mind making this a required element?
> __
> 
> 4.3.1 The CanonicalizationMethod Element 
> 
> CanonicalizationMethod is an optional element that specifies the
> canonicalization algorithm applied to the SignedInfo element prior to
> performing signature calculations. This element uses the 
> general structure
> for algorithms described in section 6.1: Algorithm 
> Identifiers. The default
> canonicalization algorithm (applied if this element is 
> omitted) is Canonical
> XML  [XML-C14N].
> 
> Alternatives, such as the minimal canonicalization algorithm 
> (the CRLF and
> charset normalization specified in section 6.5.1: Minimal 
> Canonicalization),
> may be explicitly specified but are NOT REQUIRED. 
> Consequently, their use
> may not interoperate with other applications that do no support the
> specified algorithm (see section 7: XML Canonicalization and Syntax
> Constraint Considerations). Security issues may also arise in 
> the treatment
> of entity processing and comments if minimal or other non-XML aware
> canonicalization algorithms are not properly constrained (see 
> section 8.2:
> Only What is "Seen" Should be Signed). 
> 
> We RECOMMEND that resource constrained applications that do 
> not implement
> the Canonical XML [XML-C14N] transform and instead choose minimal
> canonicalization (or some other form) are implemented to 
> generate Canonical
> XML as their output serialization to easily mitigate some of these
> interoperability and security concerns. For instance, such an 
> implementation
> SHOULD (at least) generate standalone XML instances [XML].
> 
> _________________________________________________________
> Joseph Reagle Jr.   
> W3C Policy Analyst                mailto:reagle@w3.org
> IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
>

Received on Wednesday, 3 May 2000 08:12:50 UTC