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] Feedback on SWA Profile-1.0-draft-06


Here is some clarification on item 2 & 3.

WSS provides for many ways to point the EncryptedData to the
EncryptedKey: 1) KeyInfo with a KeyName that matches an EncryptedKey
CarriedKeyName 2) KeyInfo with a RetrievalMethod of type EncryptedKey 3)
KeyInfo with a SecurityTokenReference with a Reference URI that
references the EncryptedKey.  The method WSS seems to prefer is to point
the EncryptedKey to the EncryptedData via a ReferenceList.  If every
vendor picks a different approach, we might not have much
interoperability unless all vendors support all approaches.  This is not
so much a SwA issue, except that they have specifically mentioned
ReferenceList in their draft, so I think clarification would be helpful.

Dana S. Kaufman
VP of Product Management
Forum Systems, Inc.
Tel: (781) 788-4232
E-Mail: dkaufman@forumsys.com
Visit http://www.forumsys.com
 
-----Original Message-----
From: Dana Kaufman 
Sent: Friday, July 30, 2004 2:55 PM
To: frederick.hirsch@nokia.com; wss@lists.oasis-open.org
Subject: [wss] Feedback on SWA Profile-1.0-draft-06

Here is some feedback I got from our engineers on SWA Profile 1.0 Draft
6:

1) The Content-Transfer-Encoding stuff is not clear - Section 3.1.6 item
3

"If the Content-Transfer-Encoding for the attachment has changed from
the value recorded, change the encoding of the type to match the
original encoding. Update the Content-Transfer-Encoding header if MIME
headers were included in the signature calculation."

Not sure if this item should even be in there. How do you know if the
Content-Transfer-Encoding had changed? 

Unless there is some attribute somewhere in the signature that tells you
what the encoding was previously.  There is an encoding attribute for
encryption, but not for signatures

2) There appears to be no consideration for the case where you want to
encrypt both the body and the attachments, which I think is likely to be
the common case.

3) The spec references putting an EncryptedData element in the Security
header, where WSS normally puts an EncryptedKey element with a
ReferenceList.  It is probably ok but you'll have one EncryptedData for
the SOAP Body in the ReferenceList, but the EncryptedData for the
attachment won't be in the ReferenceList.  You'll end up with duplicate
EncryptionKeys, which isn't as pretty as it could be.  You'll have the
EncryptedKey for the body in the Security header.  You'll have the same
EncryptedKey in the EncryptedData in the Security header for the
attachment.

Using the standard WSS approach of ReferenceList would eliminate this
duplication, and also be more consistent with WSS.

Dana S. Kaufman
VP of Product Management
Forum Systems, Inc.
Tel: (781) 788-4232
E-Mail: dkaufman@forumsys.com
Visit http://www.forumsys.com
 



To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
.php.




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