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
http://developer.novell.com/repository/attributes/pkisv10.pdf 
 
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>