- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Tue, 05 Jun 2001 14:44:04 -0400
- To: "Dournaee, Blake" <bdournaee@rsasecurity.com>
- Cc: "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
At 02:43 6/5/2001, Dournaee, Blake wrote: >I am a bit concerned with the use of the term "signer authentication" in the >dsig recommendation. These two sentences from the dsig (coupled with the >definition of "signer authentication" from the glossary) seem to contradict >each other: > >"... XML Signatures provide integrity, message authentication, and/or signer >authentication services for data of any type.." > >"The XML Signature is a method of associating a key with referenced data >(octets); it does not normatively >specify how keys are associated with persons or institutions..." An admittedly labored, but intended, reading of this is to note the "and/or" in the first clause. So XML Signature can contribute to signer authentication decision but is not necessarily sufficient. I've tweaked the definitions to make this clearer, and added links to those definitions in the first clause: [Resulting document: http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html $Revision: 1.66 $ on $Date: 2001/06/05 18:41:28 $ by $Author: reagle $ Authentication Code (Protected Checksum) A value generated from the application of a shared key to a message via a cryptographic algorithm such that it has the properties of [349]message authentication (and [350]integrity) but not [351]signer authentication. Equivalent to protected checksum, "A checksum that is computed for a data object by means that protect against active attacks that would attempt to change the checksum to make it match changes made to the data object." [[352]SEC] Authentication, Message The property, given an [353]authentication code/[354]protected checksum, that tampering with both the data and checksum, so as to introduce changes while seemingly preserving [355]integrity, are still detected. "A signature should identify what is signed, making it impracticable to falsify or alter either the signed matter or the signature without detection." [[356]Digital Signature Guidelines, [357]ABA]. Authentication, Signer The property that the identity of the signer is as claimed. "A signature should indicate who signed a document, message or record, and should be difficult for another person to produce without authorization." [[358]Digital Signature Guidelines, [359]ABA] Note, signer authentication is an application decision (e.g., does the signing key actually correspond to a specific identity) that is supported by, but out of scope, of this specification. Checksum "A value that (a) is computed by a function that is dependent on the contents of a data object and (b) is stored or transmitted together with the object, for the purpose of detecting changes in the data." [[360]SEC] Integrity "The property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner." [[367]SEC] A simple [368]checksum can provide integrity from incidental changes in the data; [369]message authentication is similar but also protects against an active attack to alter the data whereby a change in the checksum is introduced so as to match the change in the data. ] -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Tuesday, 5 June 2001 14:44:21 UTC