Parts of what is being described sound a lot like the stuff we're putting into PLASMA (although I think we're looking at different terms for some of it). The issue will be in how to re-use the bits in PLASMA and in REPUTE (which, I admit to not having looked at, but from this exchange sounds like it may be a way to communicate/query the policies that are used in PLASMA) and then figure out how to wedge that into more general "communication" use cases like HTTP (bundling web pages into PLASMA bundles and then doing all the complicated policy resolution stuff prior to Grandma reading them isn't going to work :).
Have fun. On 2012-01-28, at 11:10 AM, Phillip Hallam-Baker wrote: > That looks important and useful. > > It is not clear if this is quite the same application, but certainly > close. At a minimum we want to be able to transport REPUTE assertions > over whatever protocol we develop. > > I can't see a REST type protocol layered over HTTP being a viable > replacement for DNS client-recursive resolver. But whatever broker is > working is going to be wanting to pull REPUTE type data. > > > On Sat, Jan 28, 2012 at 8:34 AM, DIEGO LOPEZ GARCIA <[email protected]> wrote: >> >> On 27 Jan 2012, at 18:29 , Phillip Hallam-Baker wrote: >>> My experience of DNS is that the first is a terrible idea. The DNS >>> protocol is already stretched and there is a huge amount of legacy. >>> The DNS protocol has to serve two separate purposes, first it is the >>> protocol for communicating between the name server and the local >>> server, second between the client and the local server. It is only the >>> first of these protocols that would require tweakage. >>> >>> Another reason for not using DNS protocol is that there is >>> (potentially) a different trust model. Only some of the security >>> policy statements are coming from the DNS. In Perspectives and >>> Convergence we have data that is essentially coming from a new trusted >>> party as well. >>> >>> >>> Any new online service would have to support a UDP query mode with >>> some sort of lightweight security. It would have to support transport >>> of a range of data and there would have to be some mechanism for >>> backing off to legacy DNS when the new protocol was not available. >> >> >> What you describe here sounds very much aligned to the discussions inside >> the REPUTE WG on a lightweight reputation query protocol, for which COAP >> looks like an attractive choice. >> >> Be goode, >> >> -- >> "Esta vez no fallaremos, Doctor Infierno" >> >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >> >> e-mail: [email protected] >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ----------------------------------------- >> >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra política de envío y recepción de correo electrónico en el enlace >> situado más abajo. >> This message is intended exclusively for its addressee. We only send and >> receive email on the basis of the terms set out at >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > > -- > Website: http://hallambaker.com/ > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey --- Patrick Patterson Chief PKI Architect Carillon Information Security Inc. http://www.carillon.ca _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
