Re: importing terminology in "XML-Signature Requirements"

[Resulting version from all comments and editing should be available by
Wednesday.]

At 04:17 PM 7/13/99 -0500, Dan Connolly wrote:
 >It seems to use/import terminology liberally from other documents,
 >but not altogether consistently.

Fair enough, thank you for your comments.

 >I suggest "XML based" in place of "XML compliant" since
 >"compliant" suggests an imported definition, but that's not
 >what's going on.

Used "a XML syntax ..." (I believe "a" is the right noun determinant for the
acronym though "a" and "an" are inconsistently used through out our specs.
Massimo says "an" wins at AltaVista by an order of 5.) 

 >but I don't think that identity is an essential property
 >of a thing that you want to sign. The essential property
 >of a thing that you want to digitally sign is that it's
 >(expressible as) a sequence of bytes.

Hrmm... We want to sign digital content, certainly. But sometimes in the
signature one has an abstraction on the digital content that provides a
model of what that digital content is. In some ways, you are signing that
abstraction as well. Consequently, the syntax of the identifier in some way
provides the context/abstraction of what one means by resource... Another
way of looking at it is that we are merely signing bytes, and a (URI |
locator) is a way of invoking a chunk of bytes to be passed to the signature
application, but this way of thinking of it kills the data semantics...

 >So I'd suggest replacing that "signatures on Web resources"
 >with "signatures on digital content." So:

This is certainly true. You can sign anything you can perform the
cryptographic operation on. Is there a class of digital content that we
don't wish to sign? No. Is there a class of digital object that we can't
sign? Yes, that which is not addressable. Consequently, we could define Web
resource as any digital content that can be addressed and specified within a
signature manifest. The syntax of that address is presently defined by the
XLink locator.

 >	... signatures on digital content: content of Web resources,

Is the content of a Web resource different than the Web resource?

 >This terminology I find just baffling:
 >
 >	"More than one signature may exist over any resource."
 >
 >Given some content, a key, and a signature algorithm, surely
 >that determines exactly one signature. That's the whole point, no?
 >So I'm puzzled as to what "exist" really means. It could
 >mean any of these:
 >	(a) more than one party may sign a piece of content
 >	(b) more than one signature algorithm may be used
 >		for any XML-signature
 >	(c) since the content of a resource may change over time
 >	(or due to language preference, etc.)
 >	different signatures can be associated with different
 >	contents of a resource
 >Please be more clear which, if any, of these is meant.

Ok.

!Multiple signatures may exist for a given Web resource given varied keys, 
! content transormations, and algorithm specifications (signature, hash, 
!canonicalization, etc.). [Charter, Brown] 

One of the tricky bits here is higher level application
transformations/normalizations/serializations that happen prior to being
handed to the signature engine, is a transformed URI also handed to
represent the change? This also touches on the issue of being able to sign
the original content (the PDF file) instead of the encoded and attached
version of the original content. Richard: how did you propose to do this?

 >Another misleading reference:
 >	In conjunction with XML facilities (including packaging)
 >That seems to imply that packaging facilities are part
 >of the XML 1.0 spec that was cited above. Not so. If you mean
 >to refer to xml packaging facilities-to-be, please be more clear,
 >as that represents a dependency, which is very important to
 >call out in a requirements document. The requirement
 >	5.XML-Signatures must be able to apply to the original
 >	version of an included/encoded resource.
 >implies that you _do_ depend on an XML packaging mechanism
 >(or at least an XML datatyping mechanism for labelling
 >base64-encoded stuff as such).
 
!A key use of XML Signatures will be detached Web signatures. However, 
!signatures may be embedded within or encapsulate XML or encoded 
!content. [Charter] This WG will specify a simple method of packaging and 
!encapsulation if no W3C Recommendation is available. 

>More in the scope list...
 >	prior to handing data to a XML-Signature application.
 >the term "XML-Signature application" sprung out of nowhere.
 >I suggest you define it before the list. The definition
 >seems to be "an implementation of the XML-Signature specification."

!This document lists the design principles, scope, and requirements over
three 
!things: (1) the scope of work available to the WG, (2)  the XML signature 
!specification, and (3) applications that implement the specification. It
includes 
!requirements as they relate to the signature syntax, data model, format, 
!cryptographic processing, and external requirements and coordination.

>Talking about a piece of code in any way other than behaviour
 >that's observable from the outside is counterproductive in
 >specs. In stead of:
 >	An XML-Signature application must be able to use and understand
 >I suggest you just write:
 >	The XML-Signature specification may depend on:
 
I don't quite follow, I find the latter more ambigous. What I'm trying to
state is that a signed-XML application IS a {XLink, XPtr, XML-namespace}
application as described. (Perhaps with additional constractions.)

 >I don't understand what
 >	Applications may optionally choose C14N
 >        algorithms which do or do not process namespaces within
 >	XML content. 
 >means. I suggest you expand with an example after the list or
 >something.

ok.

 >"signature manifest" is another term that springs up unexpectedly:

fixed.

 >Under 3. "Requirements"
 >
 >There's only one RDF data model, so
 >
 >	The XML-Signature data structures will be predicated
 >	on /-an-//+the+/ RDF data model [RDF]
 
ok.

 >There's a distinction lost here:
 >	3.XML-Signatures are first class objects themselves and
 >           consequently can be referenced and signed.
 >
 >XML-signatures can be signed iff they're digital content;
 >and they are, so they can be. I think this requirement
 >talks about being referenceable, but I'm not sure I understand it.

It is reiterating a design principle actually (statements about statements). 

 >Under Format:
 >	1.An XML-Signature is XML. [Charter] 
 >huh? That sort of looks like you're saying
 >	An XML-Signature is an XML document
 >but I doubt you mean that. I think you mean:
 >	An XML-Signature is an XML element
 >but I'm not sure.

!An XML-Signature is a well-formed XML document. [Charter] 

 >This seems to import a notion of XML document type
 >that's not in the XML 1.0 specification:
 >	An XML document of a certain type must still be
 >	recognizable as its original type when signed.
 >I think you mean that if a document bears a certain
 ><!DOCTYPE ...> you must be able to sign it without changing
 >the <!DOCTYPE ...>. I think that's an impossible requirement
 >in the general case. Could you explain more clearly what
 >you mean here?

For example, an XML form, when signed, should still be recognizable as a XML
form after it has been signed.

 >Editorial: please don't use URLs as user interface.
 >Use titles as link anchors. i.e. in stead of

the present way makes the transformation to IETF ASCII easier.

 >and I think that you mean to cite the particular dated
 >specs, not any future revisions of them.

agreed.
_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://w3.org/People/Reagle/

Received on Tuesday, 20 July 1999 18:47:23 UTC