OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] WSS 1.1 Interop report


To me, the crucial phrase in XMLENC is 

"Without this information, the decryptor will be unable to automatically
restore the XML document to its original cleartext form."

There is *never* a case with EncryptedHeader where the decryptor would
be unable to restore the cleartext due to a missing Type attribute. 

Gudge

 

> -----Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
> Sent: 06 September 2005 14:32
> To: wss@lists.oasis-open.org
> Cc: Martin Gudgin
> Subject: Re: [wss] WSS 1.1 Interop report
> 
> Martin Gudgin wrote:
> [quote]
> 
> >Here is the interop report for the recent OASIS WSS 1.1 
> Interop event.
> >
> >4 parties participated. Interop was achieved between all 4 parties.
> >
> >The following issues arose;
> >
> >1.	Lines 1713-1741 (Section 9.4.4) define processing rules for
> >wsse11:EncryptedHeader. During interop testing it was identified that
> >some implementations expected
> >wsse11:EncryptedHeader/xenc:EncryptedData/@Type to be present while
> >other implementations did not emit such an attribute. Given 
> that neither
> >#Element nor #Content match the semantics of 
> wsse11:EncryptedHeader we
> >propose that the following text be added to section 9.4.4;
> >
> >	"wsse11:EncryptedHeader/xenc:EncryptedData elements SHOULD NOT
> >carry a Type attribute. Implementations MUST process
> >wsse11:EncryptedHeader/xenc:EncryptedData elements in the 
> absence of a
> >Type attribute"
> >
> >Note: 3 of the 4 parties to the interop support the above proposal.
> >
> >  
> >
> [/quote]
> 
> We are concerned that this proposed change breaks the following text 
> from XML -ENC:
> 
> [quote - Section 3.1: http://www.w3.org/TR/xmlenc-core/ ]
> |Type| is an optional attribute identifying type information 
> about the 
> plaintext form of the encrypted content. While optional, this 
> specification takes advantage of it for mandatory processing 
> described 
> in Processing Rules: Decryption <#sec-Processing-Decryption> (section 
> 4.2). If the |EncryptedData| element contains data of |Type| 
> 'element' 
> or element 'content', and replaces that data in an XML 
> document context, 
> it is strongly recommended the |Type| attribute be provided. Without 
> this information, the decryptor will be unable to 
> automatically restore 
> the XML document to its original cleartext form.
> [\quote]
> 
> Our reading of WSS and XML-ENC suggests that we should retain 
> use of the 
> Type attribute with value set to "element".
> 
> - prateek
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]