Re: Section 6.1

I don't see any particular reason to add restrictive wording.

We have defined a syntax for associating digital authentication data
with information that is being authenticated.  Just how the
authentciation data is strucutred and divided into "keying info",
Signature/Digest Value, various algorithm identifications, etc., in a
general way and specifically for the algorithms we specify is the
result of various engineering decisions on which some still
disagreement but there seems to be a clear consensus.

There are all kinds of grades of security and security model.  We
explicitly recognize and suggest public key and secret key algorithms
but recognize possible use for biometrics or as yet unknown security
models. And I think we adequately warn readers to take care in this
area.

We don't require that uses of our syntax be secure.  We don't require
any particualr strength of key or algorithm.

If someone wants to design a system that, for example, uses a
digitzied manual signature where the environment where the signature
is taken, the path to the verification point, and the system that
verifies the signature are all physically secure and all use XML why
do we want try to deny them the use of our syntax or require them to
go through the empty exercise of using the same syntax with a
different namespace?  We'll obviously fail anyway.

Donald

From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Resent-Date:  Tue, 13 Jun 2000 15:28:36 -0400 (EDT)
Resent-Message-Id:  <200006131928.PAA22653@www19.w3.org>
Message-Id:  <3.0.5.32.20000613152814.00a969b0@localhost>
X-Sender:  reagle@localhost
Date:  Tue, 13 Jun 2000 15:28:14 -0400
To:  tgindin@us.ibm.com, "Barb Fox" <bfox@Exchange.Microsoft.com>
Cc:  w3c-ietf-xmldsig@w3.org
In-Reply-To:  <852568FD.005900F1.00@D51MTA04.pok.ibm.com>

>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 Wednesday, 14 June 2000 13:54:29 UTC