Re: ACTION-638: high level reorg suggestions

Thanks Scott.

(A) I suggest we change the following paragraph in Section 1, Introduction, from

[[
XML Signature 2.0 includes a new transform model designed to address requirements including performance, simplicity and streamability. This model is significantly different than in XML Signature 1.x, see Differences from Previous version. XML Signature 2.0 is designed to be backward compatible, however, enabling the XML Signature 1.x model to be used where necessary. Details of this model are documented in XML Signature, Second Edition.
]]

to

[[
XML Signature 2.0 includes a new Reference processing model designed to address additional requirements including performance, simplicity and streamability. This "2.0 mode" model is significantly different than the XML Signature 1.x  model in that it explicitly defines selection, canonicalization and verification steps for data processing and disallows generic transforms.  XML Signature 2.0 is designed to be backward compatible through the inclusion of a "Compatibility Mode" which enables the XML Signature 1.x model to be used where necessary.
]]

(B) I also think it might be helpful to remove some of the interleaving of the modes  now that I see it in context.

Proposal:

(1) Have 2.0 Mode and Compatibility mode subsections to section 3, processing Rules

	3. Processing Rules
		3.1 Signature Generation (statement from current 3.1 and current section 3.1.3)
		3.1 2.0 Mode processing
			3.1.1 Reference Generation
			3.1.2 Reference check 
			3.1.3 Signature Validation
			3.1.4. Reference Validation
		3.2 Compatibility Mode processing
			3.1.1 Reference Generation
			3.1.2 Reference check 
			3.1.3 Signature Validation
			3.1.4. Reference Validation

(2) Modify 4.4 "The Signed Info Element" as follows:
Remove 4.4.3.3, 4.4.3.4, 4.4.3.6, 4.4.3.7-12 from 4.4.3 "The Reference Element". 
* Signature Modes
* The Transforms Element
* The DigestMethod Element
* The DigestValue Element

Add new section, "The Reference Element in 2.0 Mode", containing
* The "2.0 Mode" Transforms Processing Model
* The dsig2:Selection Element
* The dsig2:Verification element
* Subtrees with optional exclusions in 2.0 mode
* The URI Attribute for Selection in 2.0 mode
*  XPaths in 2.0 mode

Add new section, "The Reference Element in Compatibility Mode", containing

* The URI Attribute for Reference in compatibility mode
* The "Compatibility Mode" Reference Processing Model
* "Compatibility Mode" Same-Document URI-References
* The "Compatibility Mode" Transforms Processing Model

The result is:

4.4 The SignedInfo Element
	• 4.4.1 The CanonicalizationMethod Element
	• 4.4.2 The SignatureMethod Element
	• 4.4.3 The Reference Element
		• 4.4.3.1 Signature Modes
		• 4.4.3.2 The Transforms Element
		• 4.4.3.3 The DigestMethod Element
		• 4.4.3.4 The DigestValue Element
	• 4.4.4 The Reference Element in 2.0 Mode
		• 4.4.3.7 The "2.0 Mode" Transforms Processing Model
		• 4.4.3.8 The dsig2:Selection Element
		• 4.4.3.9 The dsig2:Verification element
		• 4.4.3.10 Subtrees with optional exclusions in 2.0 mode
		• 4.4.3.11 The URI Attribute for Selection in 2.0 mode
		• 4.4.3.12 XPaths in 2.0 mode
	* 4.4.5 The Reference Element in Compatibility Mode
		• 4.4.3.2 The URI Attribute for Reference in compatibility mode
		• 4.4.3.3 The "Compatibility Mode" Reference Processing Model
		• 4.4.3.4 "Compatibility Mode" Same-Document URI-References
		• 4.4.3.6 The "Compatibility Mode" Transforms Processing Model

I can help with this change if you want.

(C) other comments inline

regards, Frederick

Frederick Hirsch
Nokia



On Dec 5, 2010, at 6:27 PM, ext Scott Cantor wrote:

> I've checked in my changes, please note the following in addition to the
> intended reorgs, including a number of open editorial and normative
> questions worth resolving.
> 
> - Changed all references to "Compatibility Mode" and "2.0 Mode" to use that
> syntax exclusively
> 
> - Added dsig2: to various uses of <code>Selection<code> and other 2.0
> elements
> 
> - Clarified use of C14N 2.0 "or alternative with a compatible interface" in
> various places, please check that I didn't change any intended restrictions
> to require use of 2.0 only. The previous language was inconsistent, and in
> one case said "2.0 or greater", which seems imprecise.
> 
> - Added preamble for 2.0 schema to section 4.
> 
> - Substantial reordering and merging of material in the sections on
> Selection, Selection Types, and Verification
> 
> - Added missing schema snippets
> 
> - Changed type of DigestDataLength to nonNegativeInteger (seems more
> correct, right?)

yes assuming integer is big enough, which it should be I believe

> 
> - Added new subsections TBD for defining
> IncludedXPath/ExcludedXPath/ByteRange elements. The old section on XPath
> usage will be merged into those sections, it's commented for now.
> 
> I should have time this week to add those TBD sections, but wanted to get
> the big revision checked in ahead of the call.
> 
> Open Questions:
> 
> It seems like we need more text in 4.4.1 on requirements for alternative 2.0
> Mode C14N algorithms, much like the section on Compatibility Mode has. Also,
> seems like much of that security warning text about arbitrary algorithms
> would apply to either mode.
> 

yes


> Is Type in Reference also omitted in 2.0 Mode? Left optional? We may need to
> move the text around that describes its purpose.
> 
> May want to confirm/clarify what we say about comments and PIs: does 2.0
> c14n retain PIs? I think we said it disposes of comments, no option?

yes need to be explicit. I think now we are considering the option of retaining comments.

> 
> Spec consistency...do we want to express the Verification children as
> type-specific elements, or as a generic element with an Algorithm or Type
> attribute? Certainly everything else in the spec tends to use generic
> elements. It stuck out a bit when I was editing. Should Selection
> "type/subtype" be expressed with a single Algorithm attribute?

generic I would expect. What do others suggest?

> 
> Many of the new elements use an <any ##any> content model, instead of a bag
> of choices that include known elements and an <any ##other>  wildcard. Is
> that intentional? I've probably asked this before...

I do not believe we discussed, would have expected bag of choices with other by default. Pratik?

> 
> In the section discussing "Subtrees with Optional Exclusions", does the
> material on xml:space or xml:base still hold?

good question. I expect not, but we need to be explicit here if not.


> -- Scott
> 
> 
> 
>

Received on Monday, 6 December 2010 19:15:43 UTC