Subject: sigHTTP comments?

From: Kai Kretschmann <[email-masked]>
Date: Wed, 19 Jun 2002 18:38:09 +0200

Hi there,

Did anyone read the announcement of the internet draft about sighttp 
last may?
Any ideas, critics, comments are welcome. I did put a copy of the 
document to the website www.sighttp.org for further discussion.

thanks for reading, wkr

--
Think-Safety
www.security-gui.de

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Jun 2002 22:20:06 -0400

you might want to check out RFC 2660 - The Secure HyperText Transfer 
Protocol; this is closer to your thinking than the presently popular "HTTP 
over TLS".

the problem of ubiquitous deployment is Real Hard.....

                Harald

--On 19. juni 2002 18:38 +0200 Kai Kretschmann 
<[email-masked]> wrote:

> Hi there,
>
> Did anyone read the announcement of the internet draft about sighttp last
> may? Any ideas, critics, comments are welcome. I did put a copy of the
> -
> This message was passed through [email-masked], which
> is a sublist of [email-masked]. Not all messages are passed.
> Decisions on what to pass are made solely by Raffaele D'Albenzio.
>
>

---

From: Kai Kretschmann <[email-masked]>
Date: Fri, 21 Jun 2002 08:35:14 +0200

Hi harald,

>Protocol; this is closer to your thinking than the presently popular "HTTP 

I think our sigHTTP idea is different in at least these 3 points:
1) the signature is computed over either the entire HTML or only the static 
parts with strict conditions about the unsigned dynamic parts
2) the private key used for signing must not be on the web server, the 
content has to be presigned which makes no problem because of its static nature
3) nearly nothing has to be changed on webserver or browser side to access 
the content, the rfc 2660 seems to make much more trouble in this direction

with kind regards

--
Think-Safety
www.security-gui.de & www.sighttp.org

---

From: Eric Rescorla <[email-masked]>
Date: 21 Jun 2002 09:01:19 -0700

> document to the website www.sighttp.org for further discussion.
The system you describe appears to have a number of problems:

(1) You don't make any provision for automatic key distribution.
This makes it very difficult to scale your solution.

(2) There's no way for clients to know whether a given page
should have a signature on it. Therefore it's possible 
for an attacker who compromises the server to replace the
content with unsigned content of his own choice.

(3) <nosighttp> is insufficiently powerful. Many real systems
have large amounts of dynamic data, including substantial
HTML, on many pages. Rearchitecting these pages to isolate that
data will be difficult. 

(4) Requiring the client verifier to perform significant HTML
parsing to detect and verify the <nosighttp> elements cuts
against the claim that this solution is simple to implement.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/