[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]