RE: SACRED over HTTP (was: RE: sasl in beep or payload)
"Gareth Richards" <[email protected]> Wed, 19 Dec 2001 16:24:39 -0000
| Newsgroups | gmane.ietf.sacred |
|---|---|
| Message-ID | <[email protected]> |
> > > I believe that the argument in favour of HTTP is not that it > is a protocol > > ideally suited to the requirements of SACRED but a pragmatic one. Many > > SACRED platforms already support HTTP and since it can be used for our > > needs then if SACRED is to be widely accepted it will probably need to > > support HTTP as a transport. > > this is a misconception. the fact that HTTP is already supported on > some of the SACRED platforms does not mean that it is easier to use > HTTP than to use another protocol. HTTP actually gets in the way because > its framing and error reporting are not what you need for SACRED, > and because HTTP caches and firewalls actually degrade > interoperability. > Put it this way: those same platforms implement TCP, and TCP is a better > fit for what SACRED needs than HTTP. > One of the reasons for using HTTP is that we will be able to re-use the existing infrastructure etc and not having to invent our own framing which we would have to do if we went the TCP route. Can you explain why HTTP's framing is not suitable? > > > but there are other problems with HTTP. it's completely > unacceptable to > > > reuse port 80 or http: URIs for a new application, and bypassing site > > > security policy (e.g. firewalls) is NOT a legitimate goal. > > > > I can see that SACRED would be a new service and so should use > a new port > > etc but it can't be the only protocol considering using http > in this way > > (CMC and CMP have documented HTTP as a binding and do not seem > to tackle > > the reuse of port 80 or http: scheme). > > I'm not sure what you mean by CMC and CMP but IETF has not standardized > another application using port 80, and I suspect they are > extremely unlikely > to do so. AFAIK the only other application IETF has standardized using > HTTP is IPP, and that was a huge mistake - resulting in > unnecessary complexity > and delay in defining IPP with no measureable benefit. > CMP - Certificate Management Protocols. ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc2510bis-06.txt CMC - Certificate Management Messages over CMS ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-rfc2797-bis-01.txt