- 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