[wss] [security-jc] 9/27/2002: Document Naming Action Item

[Monica Martin <mmartin@certivo.net>]

Please note an extension on the recent conversation and a reference that
Phil has commented on.

Phil Griffin and I suggest a formal liaison to WSS from XCBF (He and I
would be happy to accommodate).

Thanks.


> 
> -----Original Message-----
> From: Phil Griffin [mailto:phil.griffin@asn-1.com]
> Sent: Friday, September 27, 2002 8:20 AM
> To: Monica Martin
> Subject: Re: [security-jc] [Fwd: Re: [wss] Document Naming Action
Item]
> 
> 
> Good idea. But keep in mind that in XCBF we define
> pure XML 1.0 messages. It just turns out that since
> our schema defines abstract values instead of concrete
> encodings that I can encode the same XCBF values in
> XMl 1.0 or in a compact binary representation.
> 
> This leads me to believe that somehow, using some
> number of attributes, I should be able to indicate
> on a security token that my schema is ASN.1 and
> my encoding is DER (that may have been base64
> armored) or that my schema is ASN.1 and my encoding
> is XER (XML 1.0 based on the ASN.1 schema).
> 
> I also need to indicate aspects of my signature
> processing. For XCBF, I have the simple X.509 like
> DigitalSignature type, the SignedData type, etc.
> And all of these, extending beyond XCBF to the
> entire range of possibilities of CMS, could be
> pure XML 1.0 or a binary encoding.
> 
> Phil
> 
> Monica Martin wrote:
> 
> 
>>http://xml.coverpages.org/ni2002-09-24-a.html
>>
>>Note the assumptions and cautions related to base64 and the overhead
>>required....Thoughts?
>>
>>Monica
========================================================================
===================================
>>-------- 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.