[xcbf] [Fwd: Re: [wss] Document Naming Action Item]

[Phil Griffin <phil.griffin@asn-1.com>]

FYI.
Phil

-------- Original Message --------
Subject: Re: [wss] Document Naming Action Item
Date: Fri, 27 Sep 2002 07:57:38 -0400
From: Phil Griffin <phil.griffin@asn-1.com>
Organization: Griffin Consulting - http://ASN-1.com
To: wss@lists.oasis-open.org
References: 
<F504A8CEE925D411AF4A00508B8BE90A03699F94@exna07.securitydynamics.com>

  From a quick read of the current draft, under "security
token formats" there may be a need for a "Biometrics
Token Profile" to enable the XCBF TC work to make use
of WSS.

But this points to the larger issue of assumptions in
the current WSS draft that I believe are invalid when
placed in an OASIS context.

Within OASIS, W3C XSD is not the only schema for XML
markup. In OASIS there are at least three schemas for
XML markup. Adding a token attribute, perhaps defaulting
to XSD, that identifies the schema would correct this
problem and allow any OASIS schema to be used.

For example, the XML Common Biometric Format (XCBF) TC
relies on an ASN.1 schema for its simple XML messages.
XCBF does not depend on any of the W3C canonicalization
mechanisms, but relies instead on the canonical XML
Encoding Rules (cXER) defined in X.694.

The assumption that cryptographically enhanced XML
content is always protected using XMLDSIG and XMLENC
is also incorrect within OASIS security TCs. Adding a
token attribute, perhaps defaulting to XMLDSIG or
XMLENC, that identifies the type of cryptographic
processing would correct this problem (in part) and
would allow any OASIS signature or encryption processing
mechanism to be used.

For example, XCBF uses the same signature processing
that is used for X.509 signatures on canonical binary
content (DER), but which in XCBF is applied to XML
markup encoded using cXER.

XCBF also uses the familiar Cryptographic Message Syntax
(CMS) types SignedData and AuthenticatedData defined in
RSA PKCS#7 and IETF SMIME. But in the XCBF work these are
based on the same ASN.1 Schema, but represented in an XML
format with all cryptographic processing  applied to
canonical XML encodings using cXER. No particular versions
of XPath, XPointer, exclusive or inclusive canonicalization
are used. Abstract values are simply encoded into XML
markup and signed.

For encryption, XML representations of the familiar CMS
types EncryptedData and EnvelopedData are used in XCBF. And
again, none of these messages rely on XSD or any of the W3C
canonicalization mechanisms, or on XMLDSIG or XMLENC for
their security.

Phil


Philpott, Robert wrote:

 > Paul Cotton, Hal Lockhart, and I received an action item at 
the f2f to
 > provide naming recommendations for documents produced by the 
TC.  At
 > this week's TC con-call, we agreed to send out a note this 
week. After
 > e-mail exchanges with Paul and Hal, I agreed to write up our 
suggestions
 > for consideration by the full TC.
 >
 >
 >
 > The main issue we attempted to deal with was to have the naming
 > convention reflect the various concerns raised at the f2f 
regarding our
 > TC's scope.  First, there is a desire to capitalize on the 
"goodwill and
 > capital" associated with the name "Web Services Security". Yet 
there is
 > also a need to deal with the strong concern by a number of 
members which
 > noted that WSS actually encompasses much more than just the 
SOAP message
 > security addressed by current "core" document. Thus they feel the
 > document names should reflect the actual document content in 
order to
 > avoid confusing the public who may think the spec's cover 
something more
 > than the titles imply.
 >
 >
 >
 > With this issue in mind, the three of us recommend the 
following approach:
 >
 >
 >
 >    1. We recommend the use of an "umbrella" tag as a prefix to all
 >       document names.  We recommend "Web Services Security" 
for this tag.
 >
 >
 >
 >    1. As stated in the current draft document labeled "Core
 >       Specification", the goal of the document is to "enable
 >       applications to construct secure SOAP message exchanges".
 >       Therefore we recommend that this document be labeled 
with one of
 >       the following:
 >
 > ·         Web Services Security: SOAP Message Protection
 >
 > ·         Web Services Security: SOAP Message Security
 >
 > ·         Web Services Security: Secure SOAP Message Exchange
 >
 > ·         Web Services Security: Core Specification (see note)
 >
 > [Note] The team was split on whether to provide "Core 
Specification" as
 > an option.  The two opinions were a) this is the key document 
of the
 > set, and b) the name does not reflect the restricted, explicit 
scope of
 > the document.
 >
 >
 >
 >    1. The additional documents that have been drafted thus far 
deal with
 >       the use of various security token formats within the 
context of
 >       the SOAP message headers.  These draft documents 
currently are
 >       labeled as "Binding" documents.  The OASIS SAML TC uses 
the term
 >       "Profile" for such documents. Either term should be 
acceptable.
 >       It is recommended here that these usage documents be 
referred to
 >       as "Token Profile" documents.  Thus, we currently would 
have the
 >       following set of documents:
 >
 > ·         Web Services Security: X509 Token Profile
 >
 > ·         Web Services Security: Kerberos Token Profile
 >
 > ·         Web Services Security: SAML Token Profile
 >
 > ·         Web Services Security: XrML Token Profile
 >
 >
 >
 > Rob Philpott
 > RSA Security Inc.
 > The Most Trusted Name in e-Security
 > Tel: 781-515-7115
 > Mobile: 617-510-0893
 > Fax: 781-515-7020
 > mailto:rphilpott@rsasecurity.com
 >
 >
 >
 >
 >



----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>