Re: Detached signatures and HTTP Redirects

> DSig folks--
> Assume the following situation: a DSIG verifier receives a detached
> signature.  When the verifier de-references the URL in the <Reference> ..
> </Reference> block, the result is an HTTP Redirect (HTTP status code 302),
> and the HTTP headers on the response include the redirected location of the
> URL.  There's also some content on the page (say a notice from the server
> that the page was redirected, typically to support old clients that don't
> natively understand redirect).
> What should the verifier do in this case?  Should it:
> a) follow the redirect URL to get the content to feed into the set of
> transforms?

Yes. Since the signature includes a digest of
the eventual body content
I don't see that following a redirect introduces
significant security risks that aren't inherent
in, say, using DNS to find the origin server
in the first place. (well... beware of bonehead
plays like looping redirects, but that's just
an operational risk, not anything terribly subtle)

I take

  <Reference URI="">
     <DigestMethod Algorithm=""/>

to refer to the body of an authorized 200 HTTP response
from , provided
that body's sha1 digest is MTblyGI... ; 

And if two HTTP transactions occur ala:

	C-> GET /bal-home.html

	->C 302 Found

	C-> GET /xyz.html

	->C 200 ...

then I consider the second response to be an
authorized 200 response from
as well. cf

similarly for 307 Temporary Redirect,
305 Use Proxy, but not 303 See Other, since
"The new URI is not a substitute reference for
the originally requested resource."

> b) use the content of the response (the server notice) as the input to the
> set of transforms?

That doesn't seem appropriate.

> c) return an error?

I think the spec should allow that, but I would consider
an implementation that signals an error in this case
to be low quality.

> Here's a concrete example: the URL is
> redirected to  Here are two signatures on
>; the first automatically followed the
> redirect and the second did not.
>  <<detached-rsa-redirect.xml>>  <<detached-rsa-noredirect.xml>>
> Section 3.2.1 (Reference Validation) is silent on this issue.
> Thoughts?

Thanks for the details; I hope my reply is as clear
as your question.

p.s. Get a Real Mailer; who uses uuencoded attachments
any more? ;-)
I decoded and re-attached them using MIME so our
HTTP archive gizmo will grok.

Dan Connolly, W3C
<Signature xmlns=""><SignedInfo><CanonicalizationMethod Algorithm=""/><SignatureMethod Algorithm=""/><Reference URI=""><DigestMethod Algorithm=""/><DigestValue>Y5SLN17HxLLMtTeuYGfYlBFmNlU=</DigestValue></Reference></SignedInfo><SignatureValue>fXPFCvR4ub+F9i93+X9Itwl/mLbrMQOroAAlS66G2Hfx7wErPciSgiE2jO0lrkU5x1HdqKoN09SzgtYzPWXb8w==</SignatureValue><KeyInfo><KeyValue><RSAKeyValue><Modulus>tfQTJczA6MEuJPpagjAsSQiibFCgrszRF/hR2xG1hICcvJLw782NxoXmbirN7aGTicJODzLzBdJNmAVQUiQMCw==</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue></KeyInfo></Signature>
<Signature xmlns=""><SignedInfo><CanonicalizationMethod Algorithm=""/><SignatureMethod Algorithm=""/><Reference URI=""><DigestMethod Algorithm=""/><DigestValue>MTblyGIP5RKDkpJu8mtJxAxqz7U=</DigestValue></Reference></SignedInfo><SignatureValue>Ir+1Cehb+5uW0iwfTkv2VzPZxCIHYZlr8br4k8oLsbea4FxudrHlmnBIY9OzpRJUOsAsHzMlQNg5fbGm0PHVHQ==</SignatureValue><KeyInfo><KeyValue><RSAKeyValue><Modulus>7cMH+nN8c7HBy1vVVQxKRiK6zb7wnu121fTQHczOEMJi58OPvcuPJT82Iofe3n3VRLf97AOxhs0H9h3l3RgRVw==</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue></KeyInfo></Signature>

Received on Tuesday, 29 August 2000 23:26:29 UTC