RE: Manually Signed Digest as an XML signature type

I've been musing over this thread.

If someone were to define a SignatureMethod where the authenticating
value was a video of the signer reading the digest or some such, then
I don't think that should go in SignatureProperties or in KeyInfo.

It seems to me that in such a case the video is that authenticating
value and should just go in SignatureValue.  If the logistics of the
signing operation make that inconvenient, you could have a varient
SignatureMethod which says that the SignatureValue is a URL to the
video data.

I don't see any necessity to put the base64 digest in the
SignatureValue but if you wanted to you could put it there and have a
compound object as SignatureValue with both the digest and the video
or pointer to the video.

Anyway, using SignatureValue seems to me like the most natural
interpretation of the draft for this out-of-scope case.

Thanks,
Donald

------- Forwarded Messages

From:  tgindin@us.ibm.com
To:  w3c-ietf-xmldsig@w3.org
Message-ID:  <852568F0.008137BD.00@D51MTA04.pok.ibm.com>
Date:  Wed, 31 May 2000 19:31:24 -0400
Subject:  Manually Signed Digest as an XML signature type

     Is there any point in the current draft which would need to be changed
to make allowances for someone to define a  "manually verifiable" signature
technique in this connection?  It may be out of scope, and it won't be
completely ready in time for the final recommendation, but it consists of
the following:

1    A new value for SignatureMethod "manuallySignedDigest".  This value
for SignatureMethod implies that the SignatureValue itself consists of the
base 64 encoding of the message digest and is not signed.  This method's
main parameter is a reference to a SignatureProperty containing the manual
signature.  It might also accept a parameter giving the data type of the
manual signature.

2    The manual signature itself, in a SignatureProperty.  This manual
signature should contain a voice recording, transcribed signature, or the
like which is performed by the user (signed with handwriting or spoken) and
in which the user him/herself records the message digest.

     This technique is not automatically verifiable, so it may not be in
scope for this group.  However, it is a way of performing a general
electronic signature using mainly pieces from the current XMLDSIG
specification.  The software verification of such a document will perform a
digest verification, but then a human will have to verify the actual
signature.

          Tom Gindin

------- Message 2

Message-Id:  <3.0.5.32.20000605192821.00be6520@localhost>
Date:  Mon, 05 Jun 2000 19:28:21 -0400
To:  "Barb Fox" <bfox@Exchange.Microsoft.com>
From:  "Joseph M. Reagle Jr." <reagle@w3.org>
Cc:  <tgindin@us.ibm.com>, <w3c-ietf-xmldsig@w3.org>
Subject:  RE: Manually Signed Digest as an XML signature type

At 03:39 PM 6/5/00 -0700, Barb Fox wrote:
 >I disagree.  We've defined KeyInfo (in just about every conceivable form!)
to mean "hints" to a verifier about where to find evidence that he is using
the correct key.  There is NO ambiguity here: the result of interpreting
KeyInfo can only be the use of a particular key by the verifier in a
cryptographic operation.  

I understood KeyInfo to be the information related to generating the
SignatureValue. Consequently if someone defined a non-cryptographic method,
KeyInfo should carry the hints appropriate to validating SignatureValue
using that method.

Your definition is appropriate as well (particularly given it's called
KeyInfo) in that KeyInfo only holds information related to generating the
SignatureValue via a cryptographic algorithm.

I just want to be clear which it is and what the implication of your
definition:
A. Non cryptographic electronic signatures should place their "validating"
information in SiggnatureProperties, or
B. Non cryptographic electronic signatures can not use XML Signature syntax
what-so-ever. (Specifying this would be difficult as we would then have to
enumerate all the algorithms that may be used, or all those that may not,
and it's difficult to enforce.)

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

------- Message 3

Date:  Mon, 5 Jun 2000 17:13:29 -0700
Message-ID:  <96BABA22ECEAEA45B53D08D63E1B567826F162@DF-SPIKE.platinum.corp.microsoft
.com>
From:  "Barb Fox" <bfox@Exchange.Microsoft.com>
To:  "Joseph M. Reagle Jr." <reagle@w3.org>
Cc:  <tgindin@us.ibm.com>, <w3c-ietf-xmldsig@w3.org>
Subject:  RE: Manually Signed Digest as an XML signature type

Joseph:

Your definition of KeyInfo is information related to the generation of
the signature.=20
Mine is that KeyInfo is information required by the verifier of a
signature.  There are several forms, like KeyName, that illustrate that
it's not intended to be used in the generation of a signature.=20

Also, in your choice between:=20

"A. Non cryptographic electronic signatures should place their
"validating"
information in SignatureProperties, or
B. Non cryptographic electronic signatures can not use XML Signature
syntax
what-so-ever. (Specifying this would be difficult as we would then have
to
enumerate all the algorithms that may be used, or all those that may
not,
and it's difficult to enforce.)"

I believe we should clearly state that compliance with this standard
requires that a cryptographic signature MUST be generated (or verified.)
If the producer of a cryptographically signed XML document wishes to add
an electronic signature, it should be included as a SignatureProperty. =20

--Barb
 
------- End of Forwarded Messages

Received on Thursday, 8 June 2000 16:28:05 UTC