- From: Brian LaMacchia <bal@microsoft.com>
- Date: Tue, 14 Mar 2000 17:41:23 -0800
- To: "'Carl Wallace'" <cwallace@erols.com>
- Cc: w3c-ietf-xmldsig@w3.org, "'Peter Hesse'" <pmhesse@cygnacom.com>
I've inlined my comments below, prefixed with [bal]... -----Original Message----- From: Carl Wallace [mailto:cwallace@erols.com] Sent: Tuesday, March 14, 2000 4:40 PM To: Brian LaMacchia; w3c-ietf-xmldsig@w3.org Cc: 'Peter Hesse' Subject: Re: KeyInfo and KeyValue Armed with an understanding of the intent, which is, as you point out, not apparent in the text, I think what you are saying is this: KeyValue provides mathematical interoperability. This appears to be the gist of your comment: "XML-DSIG must provide the base interop for doing cryptographic signature checks." [bal] Correct. "Mathematical interop" is the process of cryptographically validating the signature, and KeyValue helps with this. If this is so how is your following statement true: "there is no requirement that the verifying implementation use the specific information contained within KeyInfo in the actual signature validation." What interoperability is achieved if I can populate KeyValue with anything other than the "actual key(s) used to validate the signature?" Or do you simply mean that I may use other means to retrieve the same keying material for actual use? [bal] Your second statement is accurate; conforming applications may use other means to retrieve the same keying material. In fact, part of the reason KeyInfo is OPTIONAL is that the precise key to use may be implied by other means. One can easily envision protocols built on top of XML-DSIG that would take advantage of this option. Note that my distinction between PKI and non-PKI has nothing to do with PKIX. I was simply stating that when given a raw key from a non-PKI environment that a PKI app will fail to validate a signature generated using that key because a satisfactory certification path cannot be built. [bal] Can you help me understand why these two sentences are not contradictory? Your second sentence implies that signature validation is dependent on making a particular trust management decision about the key, and further that the trust management decision requires building a chain of certificates with some particular property. Certificates, chain building, and qualifying signature validation in this way are not fundamental to PKIs in general, although they are properties of PKIX in particular. KeyValue does not change this fact. And apparently KeyValue is not intended to do this. In any event, the parameters are superfluous and should rate a minOccurs=0. [bal] This last statement is false. If you don't include the DSA parameters then you have not fully qualified the key; without knowing the group parameters how can you mathematically validate the signature using the remaining info? Remember that the parameters are not included anywhere in the <SignatureValue> element. While the mathematical interoperability facilitated by KeyValue is important I think the text describing it creates the illusion of a interoperability at a higher level where there really isn't interoperability. By not addressing specific trust management schemes, we cannot deny their existence nor the fact that interoperability issues exist between them. Perhaps text changes shall clarify the issue. I await the next draft. -Carl [bal] Ah, I understand now, you are expecting from XML-DSIG statements on items that are specifically beyond its charter (see the Constraints subsection under Scope in http://www.w3.org/Signature/charter-20000105.html, and Design Principles & Scope items 3.1 and 3.2 in http://www.w3.org/1999/08/WD-xmldsig-requirements-990820.html). Would please identify what text in the draft led you to this expectation? It needs to be cleaned up. --bal
Received on Tuesday, 14 March 2000 20:59:41 UTC