RE: [security-jc] TAB concerns about Security JC charter

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

All,

	I have some concerns here that relate to the situation that we
may find ourselves in in five or ten years time rather than the present.
However the organizational choices we make today will have a significant
bearing on the outcome in years to come.


	One of the problems that I have seen in other standards
organizations is incumbency. Groups are established for 'guidance' and
rapidly evolve into 'architecture'. A case in point is the DNS
directorate in the IETF which is unaccountable to the IETF membership,
holds its discussions in secret and yet thought fit to act in an
oversight role on an open working group in what is allegedly an open
standards process.

	All things being equal it is generally desirable for standards
to be coherent and consistent. Certainly consistency with deployed
infrastructures, or at the least a transition plan is generally accepted
as a goal in most working groups. However such consistency must not and
should not be considered a primary objective, particularly when the
drive for 'consistency' is really an attempt to impose an untested
technology on another group.

	A case in point here was the original W3C XML Signatures group
which failled as a direct result of an attempt to link it to the PICS
project. The SACRED group in the IETF is currently being led down the
same path by the IESG's insistance that the specification be layered on
SOAP running over BEEP, despite the fact that SACRED is closely liked to
XKMS which is by default layered on SOAP on HTTP.

	There are times when a decisive break with the past, or for that
matter a misguided vision of the future is exactly what is needed.


	Discarding coertion does not mean discarding a role however, and
since in fact there is no shortage of standards bodies it is not a
matter of discarding coertion, rather it is a matter of recognizing that
it is not an available option.

	One of the frustrations of the IETF process is the lack of any
systematic review of standards after they have been deployed. This leads
to inconsistency as new standards are designed in a modular fashion
which is not retrospectively applied to older standards.

	For example work is currently taking place on XKMS (in W3C),
SAML and WS-Security. Clearly XKMS and SAML should be layered on the
components that are developed to provide a comprehensive security
infrastructure for Web Services, however a standards cannot reference a
framework that is yet to be built.

	One can imagine a situation in which the SAML group had finished
its deliverables and closed before a comprehensive framework had been
completed. It seems to me that this would be exactly the sort of
situation where a suggestion from the security joint-tc that a tc be
formed to perform a cleanup job would be sensible and useful.

	Another situation that commonly occurs is when a component of
one specification is more widely applicable. For example the assertion
framework of SAML or the protocol security protection layer in XKMS. In
such cases a suggestion that a group work on packaging that component in
a more widely applicable form is likely to be of value.


	The weight that such suggestions carry should depend on the
arguments made in their support and the individuals that make the
suggestion, not the offices they happen to hold.

		Phill

Attachment: smime.p7s
Description: application/pkcs7-signature