Robert, We're not attempting to specify policies that deployments are required to use; we're specifying minimal requirements for management interfaces to allow interoperability. Such work does belong in the IETF.
Best regards, Pasi > -----Original Message----- > From: ext [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 16 May, 2008 19:58 > To: tom.petch > Cc: [EMAIL PROTECTED]; Eronen Pasi (Nokia-NRC/Helsinki); > syslog; [EMAIL PROTECTED] > Subject: Re: [Syslog] Document shepherd report of AD concerns > > >[tom.petch] > > <rant> > > Fundamentally, someone else should be doing this, a policies in > > security working group, perhaps a spinoff from pkix or tls (which > > I know ekr will reject out of hand:-). We are the wrong people, > > IMO, to be proposing resolutions to such questions; it should be > > being done for us by those whose primary role is security, not > > network management. > > </rant> > > > > I wasn't part of that group, but I am part of the policy world. It > makes sense for the syslog group to jointly with some policy people > propose that "this is a reasonable risk analysis for the use cases > that drive our protocol". The purpose of this risk analysis is the > derivation of the underlying protocol requirements. But then, it is > just the protocol requirements that remain normative. The risk > analysis lives on for reviewers, so that they have context, and for > future users so that they can assess whether their real world > implementation risks are significantly different. If the real world > is different, it just means that you need to re-assess whether > syslog-tls will meet your needs, will need some extra mitigations, > or whatever. This keeps the policy and risk assessment portion > non-normative. So when I review something like this for policy I > want to see the analysis, but not see it become normative. > > Real normative policy work does not belong in SDOs at all. It > belongs in legislatures, regulatory groups, and business management. > I've seen far too many efforts (past and present) where people > attempt to use SDOs to bypass the public political process. They > think that making it standard lets them bypass the ugly and > difficult problems of dealing with the parliamentary process. It > doesn't work. It just means that the standards become inconsistent > with laws and regulations. That means that implementations become > inconsistent. The SDO policy thought needs to reflect instead the > consideration "what are the range of potential policies that will > apply" and make sure that the protocol is able to support the bulk > of those policies. The extra from the IESG seems to be that there > be some reasonable baseline policy that is a reasonable subset of > the bulk of the policies, and mandate that at least that much be > supported. > > That's where I end up with the basic notion of having the various > certificate stores, some sort of certificate store management, and > protocol enforcement of certificate verification. That leaves a > baseline mandatory policy assumption that there will be > bidirectional certificate verification within the protocol. All the > rest of policy becomes the rules around certificate stores and store > management. Those don't belong in syslog standard beyond the > requirement that they exist somehow. Yes, I wish there were more > agreement on the policies and the resulting needs for stores and > store management. I can see syslog contributing it's use cases and > examples to those needs. I don't see it incorporating them into the > standard, or being the right group to define them. > > I would not divorce the policy work completely. Most of the > security policy work in SDOs has been dealing with human identity > management for various authentication and authorization purposes. > That is a very different application than syslog. Those use cases > do not map well onto the automated machine logging application. > > R Horn _______________________________________________ Syslog mailing list [email protected] https://www.ietf.org/mailman/listinfo/syslog
