W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Detached signatures and HTTP Redirects

From: Brian LaMacchia <bal@microsoft.com>
Date: Tue, 29 Aug 2000 11:24:01 -0700
Message-ID: <FB9575840F91DC4EACEB5CD6F573A20DB8A062@red-msg-20.redmond.corp.microsoft.com>
To: XML DSig <w3c-ietf-xmldsig@w3.org>
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?
b) use the content of the response (the server notice) as the input to the
set of transforms?
c) return an error?

Here's a concrete example: the URL http://www.farcaster.com/bal-home.html is
redirected to http://www.farcaster.com/.  Here are two signatures on
http://www.farcaster.com/bal-home.html; 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?

					--bal


begin 600 detached-rsa-redirect.xml
M/%-I9VYA='5R92!X;6QN<STB:'1T<#HO+W=W=RYW,RYO<F<O,C`P,"\P-R]X
M;6QD<VEG(R(^/%-I9VYE9$EN9F\^/$-A;F]N:6-A;&EZ871I;VY-971H;V0@
M06QG;W)I=&AM/2)H='1P.B\O=W=W+G<S+F]R9R]44B\R,#`P+U=$+7AM;"UC
M,31N+3(P,#`P-S$P(B\^/%-I9VYA='5R94UE=&AO9"!!;&=O<FET:&T](FAT
M='`Z+R]W=W<N=S,N;W)G+S(P,#`O,#<O>&UL9'-I9R-R<V$M<VAA,2(O/CQ2
M969E<F5N8V4@55))/2)H='1P.B\O=W=W+F9A<F-A<W1E<BYC;VTO8F%L+6AO
M;64N:'1M;"(^/$1I9V5S=$UE=&AO9"!!;&=O<FET:&T](FAT='`Z+R]W=W<N
M=S,N;W)G+S(P,#`O,#<O>&UL9'-I9R-S:&$Q(B\^/$1I9V5S=%9A;'5E/EDU
M4TQ.,3=(>$Q,371497591V99;$)&;4YL53T\+T1I9V5S=%9A;'5E/CPO4F5F
M97)E;F-E/CPO4VEG;F5D26YF;SX\4VEG;F%T=7)E5F%L=64^9EA01D-V4C1U
M8BM&.6DY,RM8.4ET=VPO;4QB<DU13W)O04%L4S8V1S)(9G@W=T5R4&-I4V=I
M13)J3S!L<FM5-7@Q2&1Q2V].,#E3>F=T67I05UAB.'<]/3PO4VEG;F%T=7)E
M5F%L=64^/$ME>4EN9F\^/$ME>59A;'5E/CQ24T%+97E686QU93X\36]D=6QU
M<SYT9E%42F-Z039-175*4'!A9VI!<U-1:6EB1D-G<G-Z4D8O:%(R>$<Q:$E#
M8W9*3'<W.#).>&]8;6)I<DXW84=4:6-*3T1Z3'I"9$I.;4%6455I44U#=ST]
M/"]-;V1U;'5S/CQ%>'!O;F5N=#Y!44%"/"]%>'!O;F5N=#X\+U)304ME>59A
E;'5E/CPO2V5Y5F%L=64^/"]+97E);F9O/CPO4VEG;F%T=7)E/@==
`
end

begin 600 detached-rsa-noredirect.xml
M/%-I9VYA='5R92!X;6QN<STB:'1T<#HO+W=W=RYW,RYO<F<O,C`P,"\P-R]X
M;6QD<VEG(R(^/%-I9VYE9$EN9F\^/$-A;F]N:6-A;&EZ871I;VY-971H;V0@
M06QG;W)I=&AM/2)H='1P.B\O=W=W+G<S+F]R9R]44B\R,#`P+U=$+7AM;"UC
M,31N+3(P,#`P-S$P(B\^/%-I9VYA='5R94UE=&AO9"!!;&=O<FET:&T](FAT
M='`Z+R]W=W<N=S,N;W)G+S(P,#`O,#<O>&UL9'-I9R-R<V$M<VAA,2(O/CQ2
M969E<F5N8V4@55))/2)H='1P.B\O=W=W+F9A<F-A<W1E<BYC;VTO8F%L+6AO
M;64N:'1M;"(^/$1I9V5S=$UE=&AO9"!!;&=O<FET:&T](FAT='`Z+R]W=W<N
M=S,N;W)G+S(P,#`O,#<O>&UL9'-I9R-S:&$Q(B\^/$1I9V5S=%9A;'5E/DU4
M8FQY1TE0-5)+1&MP2G4X;71*>$%X<7HW53T\+T1I9V5S=%9A;'5E/CPO4F5F
M97)E;F-E/CPO4VEG;F5D26YF;SX\4VEG;F%T=7)E5F%L=64^27(K,4-E:&(K
M-757,&EW9E1K=C)6>E!:>$-)2%E:;'(X8G(T:SAO3'-B96$T1GAU9')(;&UN
M0DE9.4]Z<%)*54]S07-(>DUL44YG-69B1VTP4$A62%$]/3PO4VEG;F%T=7)E
M5F%L=64^/$ME>4EN9F\^/$ME>59A;'5E/CQ24T%+97E686QU93X\36]D=6QU
M<SXW8TU(*VY..&,W2$)Y,7965E%X2U)I2S9Z8C=W;G4Q,C%F5%%(8WI/14U*
M:34X3U!V8W502E0X,DEO9F4S;C-64DQF.3=!3WAH<S!(.6@S;#-29U)6=ST]
M/"]-;V1U;'5S/CQ%>'!O;F5N=#Y!44%"/"]%>'!O;F5N=#X\+U)304ME>59A
E;'5E/CPO2V5Y5F%L=64^/"]+97E);F9O/CPO4VEG;F%T=7)E/@==
`
end
Received on Tuesday, 29 August 2000 17:52:29 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:11 GMT