Re: [wss] WSS Issue#1: Support for carrying PKCS7 Encryption Payloadsin SOAP Message

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

Rich Salz wrote:
> > A complete XML only version of CMS is being progressed in X9, X9.96 XML
> > Cryptographic Message Syntax (XCMS). This work should be completed by end
> > of first quarter next year.
> >   
>
> How do you see the future of XCMS compared and contrasted to XML
> DSIG/XML-Encryption?  Are vendors going to have to support both?
> 	/r$
Hi Rich. 
 
 Vendors aren't "required" to do anything really. I'm asking for the WSS
token design to
be more flexible. Vendor opportunity will be provided if alternative approaches
are not 
purposely excluded in the design. 
 
 If you've already got CMS product and deployment XCMS is a way to extend
the useful
life of your companies and your customers investment.  And if the input to
your signature 
and encryption processing is a pointer to a string, it doesn't much matter
to your code if the
string is binary or XML markup.
 
 And supporting another canonical encoding rule, one that arguably is more
simple than DER,
is far less of a hit than adding support for xmldsig and xmlenc to products
that still must rely
on the likes of ASN.1 based objects such as X.509 Certificates. To do this
you must support
another schema, another signature process, one or more canonicalization methods,
... So, the
present is already hybrid,  and the future would seem to need to support
both document and
message transactions.
 
 You know, I can prefix an XCBF  value of  <BiometricObject> 
with a document header
like  "<?xml version="1.0" encoding="UTF-8"?>" and call it a document.
But it  is not a 
document really. It's much more simple than that. And all it takes to sign
the value or encrypt 
it is to simply encode the value in DER or XER. Same method, different surface
string format.
 
 The data is so simple that it doesn't really deserve to be treated as a
tree. An application is free
to treat it as the developer sees fit - a tree if they wish, but a simple
C struct will probably do. 
And for high volume transaction systems, a simple XER encode and sign approach
may well 
turn out to be best for known and expected XML data that is arguably not
an arbitrary XML
document.

 I'm not sure what the future will bring. I suppose that we'll never get
to a world where one
size fits all. As to XCMS, the NWI proposal says that I'll extend the current
CMS capability
to provide a means of signing arbitrary components of types. Easy enough
really when these
can be identified using their schema specified markup tag names and an OID
in a signed
attribute. But I don't really see this as the primary driver of this technology.
I see speed  and
processing simplicity as the key benefits. Though for biometrics use message
size and speed
of processing are the critical concerns.
 
Phil
    
 


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