- From: TAMURA Kent <kent@trl.ibm.co.jp>
- Date: Thu, 5 Oct 2000 16:32:46 +0900
- To: w3c-ietf-xmldsig@w3.org
In message "Re: Comments on XML-Signature S&P draft" on 00/10/04, "Joseph M. Reagle Jr." <reagle@w3.org> writes: > Yes, I goofed in my scenario, I'll try again: > > Author creates signature that includes a reference to KeyInfo element (it is > signed) in a separate document via a relative URL. The > CanonicalizationMethod absolutizes the URI via some arbitrary method. (Also, > the SignatureMethod could be changed in some way too). > > The thing that's necessary is that the applications validate that which was > signed. So in section 3.2.2 the only thing that the applications deals with > is the KeyInfo (and while it need not be signed, if it is we should protect > it appropriately) and the SignatureMethod. If either of these could've been > altered by the CanonicalizationMethod, then the canonicalization step in > validation should correspond to the canonicalization in generation in 3.1.2.2. I still have strangeness. In your scenario, signature applications can not get correct meaning of a KeyInfo only from the KeyInfo itself. Transformed results of Reference elements are usually used only for digest calculation. Signature applications have to re-parse transformed results of KeyInfo References, but applications can not know whether a reference points a KeyInfo or not before re-parsing. (Note that even if the URI attribute of a Reference element points a KeyInfo element, transformd result would not always become a KeyInfo element.) -- TAMURA Kent @ Tokyo Research Laboratory, IBM
Received on Thursday, 5 October 2000 03:33:21 UTC