Re: Verification Response Proposal: Toolkits ought to return bytes of verified data to the application

You comments are "valid", umm, I mean "veritable" ;-)   

I chose verify() simply because this is the method name commonly used in
existing Toolkits.  But wrt to the definitions you wrote, the name validate()
would be clearer (particularly for those keeping the Latin definitions in
mind).

Indeed, it needs to be well understood that just because a Signature is
"valid" does NOT mean the context in which it is being processed is "verified".
 This is illustrated by the example I had in mind, but not on paper, when
I wrote my original note.  The example went something like this...


The Bank of Nirvana uses XML Signatures to protect its money transfers.
 For example:

<?xml version="1.0" encoding="UTF-8"?>
<MoneyTransfer>
<Body ID="MoneyTransferBody">
	<From>Bank of Nirvana</From>
	<To>Ed Simon</To>
	<Amount Currency="USD">
123.45
</Amount>
</Body>

	<Signature xmlns:xsig="http://www.w3.org/.../Signature">
	<SignedInfo>
	<Reference URI="#MoneyTransferBody">
	<Digest>abc...123</Digest>
	</Reference>
	</SignedInfo>
	<SignatureValue>ABC...123</SignatureValue>
	</Signature>
	
</MoneyTransfer>

(Note: In the above example, it might have been more realistic to sign the
whole <MoneyTransfer> object excluding the <Signature> with the XPath Enveloped
Signature Transform.  For clarity's sake, I haven't.)

When recieving a <MoneyTransfer> document, the Bank's software:

1.  Locates the XML Signature.
2.  Calls the API XmlSignature.verify().  Note: the verify() method performs
the XML Signature spec's prescribed core validation.
3. if the verify() method returns true (the signature validated), the money
is transferred.

The problem is that if the following is received...

<?xml version="1.0" encoding="UTF-8"?>
<MoneyTransfer>
<Body ID="MoneyTransferBody">
	<From>Bank of Nirvana</From>
	<To>Ed Simon</To>
	<Amount Currency="USD">
1234567.89
</Amount>
</Body>

	<Signature xmlns:xsig="http://www.w3.org/.../Signature">
	<SignedInfo>
	<Reference URI="#MyDog">
	<Digest>xyz...789</Digest>
	</Reference>
	</SignedInfo>
	<Object ID="MyDog">My dog has fleas</Object>
	<SignatureValue>XYZ...789</SignatureValue>
	</Signature>
	
</MoneyTransfer>

...the money still gets transferred because the bank's software gets a positive
signature validation.  The problem is the signature only attests that "My
dog has fleas" not the money transfer.  Not a good thing (for the bank or
the dog).

The problem can be avoided in two ways:
1) The <MoneyTransfer> document is validated against a secure syntax (eg.
a strongly typed schema) to ensure the right ID and URI attributes are correctly
specified in the right places.
2)  The Toolkit can return the actual validated, signed bytes which are
then used by the app for further processing.  In the above example, the
processing would fail because "My dog has fleas" is not a money transfer.
3) Do both of the above.

Generally, I figure option 3 is ideal but in specific application scenarios,
options 1 or 2 might be appropriate.  

Given that option 1 will often not be satisfactory (and would almost never
be for references outside the document), Toolkits ought to have a verify()
methods like I described in my previous note.  And as Joseph rightly  points
out, they really ought to be called validate() not only to be true to the
words' Latin roots, but because we need to emphasize what a Signature does
and doesn't do. 

Regards, Ed


-- Original Message --

>On Tuesday 08 January 2002 20:59, edsimon@xmlsec.com wrote:
>> a) a basic verify() method that simply indicates whether the XML
>> Signature is valid or not (I think all Toolkits already do at least this)
>
>I agree with your suggestion but at a completely editorial-nit-picking

>level I'd recommend that such methods be called "validate". For 
>better-or-worse that's the word the specification uses. (I understand this
>
>is inconsistent with other usage but it is consistent (in my understanding)
>
>with RFC2828 in that we needed to strongly focus on our "0-to-light-weight"
>
> signature semantics: Signature Validation is "a process intended to 
>establish the soundness or correctness of a construct." xmldsig ruled trust
>
>out of scope and consequently says nothing with respect to the truth, 
>accuracy, or trustworthiness of the thing being signed, only in the 
>soundness of the XML Signature.)
>
>[1] http://www.ietf.org/rfc/rfc2828.txt
>
>      ISDs SHOULD comply with the following two rules to ensure
>      consistency and to align Internet security terminology with
>      ordinary English:
>
>       - Rule 1: Use "validate" when referring to a process intended to
>         establish the soundness or correctness of a construct. (E.g.,
>         see: certificate validation.)
>
>       - Rule 2: Use "verify" when referring to a process intended to
>         test or prove the truth or accuracy of a fact or value. (E.g.,
>         see: authenticate.)
>
>      The rationale for Rule 1 is that "valid" derives from a word that
>      means "strong" in Latin. Thus, to validate means to make sure that
>      a construction is sound. A certificate user validates a public-key
>      certificate to establish trust in the binding that the certificate
>      asserts between an identity and a key. (To validate can also mean
>      to officially approve something; e.g., NIST validates
>      cryptographic modules for conformance with FIPS PUB 140-1.)
>
>      The rationale for Rule 2 is that "verify" derives from a word that
>      means "true" in Latin. Thus, to verify means to prove the truth of
>      an assertion by examining evidence or performing tests. To verify
>      an identity, an authentication process examines identification
>      information that is presented or generated. To validate a
>      certificate, a certificate user verifies the digital signature on
>      the certificate by performing calculations; verifies that the
>      current time is within the certificate's validity period; and may
>      need to validate a certification path involving additional
>      certificates.
>
>
>
>-- 
>
>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/
>

-----------------------------------------------------------------------------------------------
Ed Simon
<edsimon@xmlsec.com>
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit "www.xmlsec.com".

Received on Wednesday, 9 January 2002 13:20:25 UTC