[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

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 <> 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:]
> Sent: 
Monday, November 11, 2002 7:01 PM
> To: David Orchard
> Cc: 
; 
> 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>