[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wss] Key Quality and Protection Assertions and WDSL
Hello, David - it seems I piped up on a call a time or
two
in the past with some mutterings surrounding this issue,
and
promised to ping you about them.
My particular area of interest has to do with the way in
which
the quality of assertions may be ascertained, or requested,
when
looking for assertion providers to assert things (!), or
when
a relying party is looking for corroboration for an
assertion
present in a message. There is certainly going to be
disagreement
in the community as to whether such quality metrics
are
possible, or how to boot strap such a thing if it is possible,
but I think it IS possible, and such quality assertions, which
is
what they really are, can be the basis for liability
allocation
as transactions increase in value.
The tricky part comes in agreeing upon a cannoncialized
representation of the quality measure assertions
(there
would seem to need to be more than one - for
example:
a) key generation quality, ala FIPS 140-2
criteria
b) crypto quality, ala FIPS 140-2 criteria
c) key protection, ala common criteria or TCSEC
criteria
and, indeed, there may be more). The scheme Novell
has
used involves an unsigned 8 bit value for each to
represent
an ordered rating - which rating is bound to be subjective -
but which can be used to compare between required
assurances vs. proffered assurances.
Can you lie? Yeah, so this scheme, by itself, doesn't
address
the whole trust-chain computation issue (we have
other
approaches to that), but it's very useful to be able to
compute
a greatest least bound on the chain of handlers to see
what
the weakest link (and thus the overall strength) of the
chain
is...and that's what insurers like about it.
An earlier version of the spec, which Novell uses in our
CA
and in our own code signing PKI Hierarchy, is available
at
The spec, as it stands, needs revision, but it does, I
think
present a useful way to represent key protection
assurances
that relying parties can use.
How does this relate to WDSL? Or WSS in
particular?
I'm not sure. The quality metrics can be
applied to more than just key quality and protection. My
question, I suppose (long time getting to it) is whether
such
assertions, about the quality of the service provider
interface
itself, are relevant to the WDSL advertisement or not,
and
(separately) whether they can/should be
referenceable
in the security tokens of which they're a part?
I suppose the general question of references has to do
with
how a extended attributes in, for instance, and
X.509v3
certificate token, can be surfaced and referenced
elsewhere
in the environment for processing. Which is probably
best
directed at the X.509v3 security token profile
authors.
Regards,
Ed Reed
===============
Edwards E Reed, Security Tzar Novell, Inc. +1 585 624 2402 - Rochester +1 617 914 8011 - Cambridge +1 585 750 2960 - Cell >>> David Orchard <dorchard@bea.com> 11/17/02 10:43PM >>> Hi Rich, Apologies for my delay, it's been a crazy few weeks of meetings. I think the issue around WSDL is that it is possible to have many different ways of expressing the requirements on the header. And it would be good have a clean and interoperable way of expressing these. WSDL 1.1 and 1.2 provide frameworks for extension to specify required headers. Clearly wsdl WG won't define specific extensions for various header blocks, so this discussion is orthogonal to wsdl wg's work. Currently, the ws-security header element is fairly generic. It's really the contents of the header that a service will be interested in specifying. For example, a service could say that message integrity is required. I'll avoid for the purposes of this discussion about the extent of the potential properties that might also be required, such as CA, particular type of c14n, etc. So how does an application specify that message integrity is required? Simply saying the header is required probably does very little for interop. And now for my $.02 worth of some similar context. SAML went through a similar issue, which was how does one query for a particular type of assertion data. There was movement away from generic assertion to strongly typed assertions specifically because of the difficulty in writing interoperable constructs(queries) that specify the response data, including types. WS-Security without WSDL is akin to SAML Assertions without SAML queries. There would be no way of having SAML interop without SAML Queries - simply saying that SAML should define assertions wasn't nearly sufficient. I know the analogy isn't perfect, but it shows a similar relationship. I personally foresee similar kinds of difficulties in defining requirements on ws-security content for a service. The ability to clearly specify the data requirements for ws-security header element in a WSDL document is crucial for real interop, and particularly interop without some kind of private agreement. And it seems that defining the WSDL extensions for ws-security is better done in the oasis ws-security tc, rather than somewhere else like ws-i. Cheers, Dave > -----Original Message----- > From: Rich Salz [mailto:rsalz@datapower.com] > Sent: Monday, November 11, 2002 7:01 PM > To: David Orchard > Cc: wss@lists.oasis-open.org; www-ws-arch@w3.org > Subject: Re: [wss] Issue on WS-Security and WSDL definitions > > > Dave, > > I'm not current on WSDL 1.2, but can you explain a bit how WSDL fits > in here? It seems to me that a stand-alone specification should just > define the semantics of its elements. If an application wants those > semantics, then the application WSDL should specify the header as > being required. > > What am I missing? > /r$ > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> > ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC