[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 312 proposed resolution
Dana Thank you for the useful feedback provided in issue 312. To address issue 312 I propose the following changes to the SwA profile draft 7: 1. Clarify that when an wsse:Security/EncryptedKey element is used to convey an encryption key, then when that key is used to encrypt an attachment, the EncryptedKey/ReferenceList element must contain a reference to the wsse:Security/EncryptedData element corresponding to the attachment. 2. Clarify that when the same EncryptedKey corresponds to multiple EncryptedData elements, then the EncryptedKey/ReferenceList should contain a reference for each (corresponding to both attachments and primary soap envelope items). Order of references should correspond to ordering of security header elements (most recent encryption first in list). 3 Clarify that when an EncryptedKey element is not used when encrypting an attachment, then the EncryptedData element must contain a KeyInfo and specify a key according to the preferences outlined in core. Different deployments may have different requirements here so key management interoperability is out of scope. 4. Add a processing rule that when encrypting both attachments and primary SOAP envelope content using the same key, perform the attachment processing first. The reason is that core states that elements should be prepended to the security header. This way the EncryptedData element will be put first in the header with EncryptedKey and tokens following (i.e. receiver should be able to pop EncryptedKey off stack before the EncryptedData). I have attached a note outlining encryption of both a SOAP body and attachment, along these lines. I suggest that it is ok to have a KeyInfo in an EncryptedData element even when using the EncryptedKey ReferenceList mechanism, but that a receiver should be able to rely upon the ReferenceList mechanism (as reflected in the proposed changes above.) Does this address issue 312? I also suggest we clarify in the core specification that if an EncryptedData element is referenced in a wsse:Security/EncryptedKey/ReferenceList, then no wsse:Security/ReferenceList reference is also required for that encryption. I also note a typo in the X.509 token profile, x509 should be x509v3 in the table at line 187. Thanks Regards, Frederick Frederick Hirsch Nokia -----Original Message----- From: ext Dana Kaufman [mailto:dkaufman@forumsys.com] Sent: Friday, July 30, 2004 2:55 PM To: Hirsch Frederick (Nokia-TP/Boston); wss@lists.oasis-open.org Subject: Feedback on SWA Profile-1.0-draft-06 Here is some feedback I got from our engineers on SWA Profile 1.0 Draft 6: 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
--- Begin Message ---
- From: <dkaufman@forumsys.com>
- To: <wss@lists.oasis-open.org>
- Date: Tue, 10 Aug 2004 11:02:01 -0400
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. 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.--- End Message ---
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]