RE: Canonical XML 2.0 Conformance Profiles

We are treading a fine line here.  If we mark too many features as MUST implement, we won't get many implementations, on the other hand if we have too many OPTIONAL features nobody will implement them and they will fall into the sidelines.

 

It is useful to have a profile which has only C14N 1.x features. This can be very easily implemented by existing libraries, they just have to recognize the new syntax.

 

Pratik

 

From: Meiko Jensen [mailto:Meiko.Jensen@ruhr-uni-bochum.de] 
Sent: Friday, September 03, 2010 1:26 AM
To: Frederick.Hirsch@nokia.com
Cc: public-xmlsec@w3.org
Subject: Re: Canonical XML 2.0 Conformance Profiles

 

HYPERLINK "mailto:Frederick.Hirsch@nokia.com"Frederick.Hirsch@nokia.com schrieb: 

To repeat what I think you said, Does this mean there are really two conformance levels?
 
1. Support C14N2 with defaults as listed for all parameters. All other parameters not at default settings are optional.
 
2. Also support ExclusiveMode, InclusiveNamespace, IgnoreComments and XmlAncestors parameters with values other then defaults.
  

I'm saying that, yes, you could read the spec document both ways. By now, the spec says (in 2.2.1) "Implementations may not support all of these parameters. We have identified the following profiles.", but it does not explicitly say how these profiles relate to conformance (i.e. whether all of these profiles have to be supported, at least one of them, or none of them...). I also remember Pratik saying that implementers were allowed to decide upon which profiles they support, meaning them to be optional.

Besides that I'd also like to point to the fact that both definitions of conformance imply that all our new parameters (such as TrimTextNodes, prefixRewriting etc.) are optional to implement. Hence, the difference between C14N1.X and C14N2.0 turns out to merely be suggesting a list of optional-to-implement, optional-to-use new params, and to require backward compatibility. I have to admit that I'm not really satisfied with this, since---to me---those new parameters are very useful in practice, but if they remain optional, this means that you can never rely on that your signature peer (i.e. in most cases the verifier) supports the same set of XML Signatures as you do. We're fuzzying the feature list of the XML Signature spec bundle here, and frankly, I'm not sure this is a good approach for a soon-to-be standard document.

just my $.02

cheers

Meiko



 
 
 
regards, Frederick
 
Frederick Hirsch
Nokia
 
 
 
On Sep 2, 2010, at 8:24 AM, ext Meiko Jensen wrote:
 
  

I've taken a look at the conformance profiles of canonical XML 2.0 as
published on August 31st.
 
By now it seems that this specification---as it is now---implicitly
supports three different levels of "REQUIRED/OPTIONAL" for conformance.
 
The first level is shaped by the default values for all parameters:
since this is the default, *every* conforming implementation must
support this configuration.
 
The second level is shaped by the three "conformance profiles"
explicitly listed in section 2.2.1:
-ExclusiveMode="true" must be supported for the "1.x features" and "1.x
Simple Exclusive" profile (and I'd recommend it as well for streaming),
but since its default value is "false", a conforming implementation must
support this one in full.
-InclusiveNamespace must be supported as well, though default being an
empty list
-IgnoreComments="false" must be supported for "1.x features"
conformance, though default is "true"
-XmlAncestors="none" must be supported for "1.x features", though
default is "inherit"
Hence, these 4 parameters (and all of their combinations) are REQUIRED
to implement for conformance with the spec.
 
The third level is shaped by all parameters listed in the spec, but
which are not deviating from their default values for any of the given
profiles. Hence---as I read it now---these are  OPTIONAL to implement.
-SortAttributes: though being listed explicitly in all the profiles, its
value is always set to "true", hence it is not required to support the
"false" case for any of the profiles nor the default.
-TrimTextNodes: always set to "false" => OPTIONAL
-Serialization: always set to XML => OPTIONAL (btw: the spec says
"serializeXML" as default, "Xml" as value in the profiles, and "XML" as
enum value in the XML Schema. Should be unified)
-PrefixRewrite: always set to "none", rendering "sequential" and
"derived" OPTIONAL
-QNameAware="": listed explicitly, but for conformance it is only
REQUIRED to support the empty version of this parameter (which means
doing nothing about this). => OPTIONAL
 
The implicit 4th level is that people might start creating their own
parameters and switches here, but I think that's out of scope for the
specification.
 
 
To resume, we require only the conformance to the backward-compatibility
profiles. Everything "new" is rendered OPTIONAL, hence will not affect
conformance nor interops, right?
 
This should close my Action-625 for now.
 
best regards
 
Meiko
 
-- 
Dipl.-Inf. Meiko Jensen
Chair for Network and Data Security 
Horst Görtz Institute for IT-Security 
Ruhr University Bochum, Germany
_____________________________
Universitätsstr. 150, Geb. ID 2/411
D-44801 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// HYPERLINK "http://www.nds.rub.de"www.nds.rub.de
 
 
    

 
  





-- 
Dipl.-Inf. Meiko Jensen
Chair for Network and Data Security 
Horst Görtz Institute for IT-Security 
Ruhr University Bochum, Germany
_____________________________
Universitätsstr. 150, Geb. ID 2/411
D-44801 Bochum, Germany
Phone: +49 (0) 234 / 32-26796
Telefax: +49 (0) 234 / 32-14347
http:// HYPERLINK "http://www.nds.rub.de"www.nds.rub.de