RE: Section 6.1

At 12:12 PM 6/13/00 -0400, tgindin@us.ibm.com wrote:
 >     The two changes have distinct purposes.  First, and less
 >controversially, the wording you suggested does NOT clearly rule out pure
 >digest algorithms as cryptographic signatures.

Thank you guys for helping push and resolve this ambiguity. Given the weight
of the text in the requirements document [1] and the spec [2], and
subsequent discussion I think we can agree that the intent is to preclude
the above. In the interest of clarity, I recommend an amendment to Barb's
proposed text:

"This specification defines a set of algorithms, their URIs, and
requirements for implementation. In general, requirements apply to
implementations, not to signature use. However, this specification REQUIRES
/+the use of +/ cryptographic SignatureMethods /+and key(s)+/ for
SignatureValue generation and verification. Other authenticators
(electronic, biometric, etc.) may be included ONLY as a supplement to the
cryptographic signature via the SignatureProperty element type."

I include /+the use of +/ so as to not mislead readers to think the key must
be present in the syntax as that is optional.
 
 >Second, my wording leaves open the question of
 >whether a subsequent version will or will not support manually verifiable
 >signatures, rather than leaping to a conclusion on the subject.

As we discussed out-of-band, there was a slight disconnect in our usage of
the term versions, with it being out of scope in both <smile>:

A. Version as the different status levels (proposed, draft, internet /
candidate, proposed, rec). Because of the joint nature, this WG has been
atypically aggressive in not permitting optionality or future
reconsideration. Instead we ask: is this in keeping with our stated
requirements and dependencies and does anyone plan to implement this soon?
We've been doing our best to write the spec based on that which has already
been captured in the requirements, implemented and as if we expected it to
be a standard tomorrow.

B. Version as in other namespaces/activities/specs. It is my sincerest hope
that when this spec is done, this WG will end. Others can easily use our
syntax and schema by importing it into their own under their own namespace.
If it turns out that namespace for 'electronic signatures' and its
element-types become immensely successful so be it, but the good result is
we don't have to have that argument here.

__

[1] http://www.w3.org/TR/1999/WD-xmldsig-requirements-19991014.html
2.3 The meaning of a signature is simple:  The XML-signature syntax
associates the content of resources listed in a manifest with a key via a
strong one-way transformation. 
2.5 The specification must only require the provision of key information
essential to checking the validity of the cryptographic signature
3.3.1 The specification must permit arbitrary cryptographic signature and
message authentication algorithms, symmetric and asymmetric authentication
schemes, and key agreement methods. 
[2] http://www.w3.org/TR/2000/WD-xmldsig-core-20000601/
4.3.2 The SignatureMethod Element
SignatureMethod is a required element that specifies the algorithm used for
signature generation and validation. This algorithm identifies all
cryptographic functions involved in the signature operation ...
6.1 Algorithm Identifiers and Implementation Requirements
For example, a SignatureMethod is implicitly given two parameters: the
keying info and the output of CanonicalizationMethod. 
6.1 Algorithm Identifiers and Implementation Requirements
[digest and signature algorithms are distinguished]


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

Received on Tuesday, 13 June 2000 15:28:26 UTC