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: SwA Profile Lines 352-353


In the latest draft of the SwA profile, the statement is made that when an
<EncryptedKey> element is used, no <KeyInfo> should be present. This seems
wrong to me. Why is this restriction here? This would mean that referring to
an X.509 certificate either directly or indirectly couldn't be done:

<xenc:EncryptedKey Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey";
Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"; />
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#";>


Blake Dournaee
Sarvega, Inc.

-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com] 
Sent: Thursday, August 19, 2004 1:48 PM
To: dkaufman@forumsys.com; wss@lists.oasis-open.org
Subject: [wss] Issue 312 proposed resolution


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

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

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

I also note a typo in the X.509 token profile, x509 should be x509v3 in
the table at line 187. 


Regards, Frederick

Frederick Hirsch

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

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

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

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