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


Your argument assumes that the XML decryptor is WSS aware. For the 
general case of XML decryption, the XML-ENC processing rules "STRONGLY 
RECOMMENDS" setting the xenc:EncryptedData/@Type.

IMO, your proposed text runs counter to the decryption processing rules 
in Section 4.2 of XML-ENC by requiring that the xenc:EncryptedData/@Type 
be omitted.

~ Vamsi

Martin Gudgin wrote:
> 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
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 
> 




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