RE: [wss] Comments on WSS-X509 draft 06-05 merged.pdf

[Tim Moses <tim.moses@entrust.com>]

Toshi - Thanks for you response.  Two reactions:

1. I am concerned that it will not always be possible to assign each
recipient to a role that can be agreed between all parties.  In some cases,
there may be more than one intended recipient, but the sender is not able to
distinguish between them on the basis of role, only on the basis of
identity.  So, I prefer that it be "optional" to address each recipient by a
separate role, and therefore, by a separate header.

2. I should have realized this earlier, but, in the case of encryption, it
is possible and (perhaps) desirable for all references to be backwards,
because backward references allow the message to be encrypted in a single
pass.

Single-pass encryption requires that the sender know the security policy
and, therefore, how many symmetric keys are required and for whom they have
to be encrypted at the outset: not an unreasonable requirement.

The situation for signatures is different: if the signature goes in a
header, then the header cannot be prepared until all the necessary elements
have been digested.  So references from the signed elements to the signature
would not enable single-pass processing.  And references from the signature
to the signed elements have other advantages.

In the (perhaps unusual) case where there are multiple signatures verifiable
by the same certificate, it is desirable for the reference to go from the
signature to the certificate.  Then the certificate reference does not have
to be modified with the introduction of each new signature.

As signatures cannot be produced by a single forward pass through the
message, perhaps, it is not important that encryption be performed that way.
Perhaps, consistency between the procedures for creating signatures and for
encryption is more important.

On balance, I propose the following reference flow.  But, I am certainly
interested to hear others' opinions. 

Encryption:-
IssuerSerial <- EncryptedKey <- EncryptedData

Signature:-
BinarySecurityToken <- Signature -> signed element

All the best.  Tim.

-----Original Message-----
From: NISHIMURA Toshihiro [mailto:nishimura.toshi@jp.fujitsu.com]
Sent: Friday, July 11, 2003 4:03 AM
To: wss@lists.oasis-open.org
Subject: Re: [wss] Comments on WSS-X509 draft 06-05 merged.pdf


Tim,
I see your proposal has two points.

1. <wsse:compartment> element
  I think your requirement is satisfied by using S:role attributes.

  - A message sender encrypts some part of the message using a
    symmetric key.
  - The sender encrypts the symmetric key using Recipient1's
    key-aggreement key and put it in 
    <wsse:Security S:role="Recipient1"> element using
    <xenc:EncryptedKey> element.
  - <ds:KeyInfo> element for Recipient1's key-aggreement key is also
    added in the <wsse:Security S:role="Recipient1">.
  - The sender encrypts the same symmetric key using Recipient2's
    key-aggreement key and put it in 
    <wsse:Security S:role="Recipient2"> element
    and so on.

  I attached the sample.

2. References flow
  Your proposal adds <wsse:Reference> element in <ds:KeyInfo> element
  and achives the following flow.

    ds:KeyInfo    
      Reference -> xenc:EncryptedKey(Compartment) -> message element

  With current spec, the flow will be:

                  xenc:EncryptedKey       -> message element
    ds:KeyInfo <-   ds:KeyInfo

  or
                           ds:Signature   -> (signed) message element
    BinarySecurityToken <-   ds:KeyInfo

  Is it better we also allow <wsse:Reference> element in
  <BinarySecurityToken> element?

    BinarySecurityToken
      Reference         -> ds:Signature   -> (signed) message element

---
Toshi

---
NISHIMURA Toshihiro (FAMILY Given)
nishimura.toshi@jp.fujitsu.com
XML/Web Services Technology Dept.,
STRATEGY AND TECHNOLOGY DIV., FUJITSU LIMITED


At Fri, 04 Jul 2003 15:39:39 -0400,
Tim Moses wrote:
> 
> [1  <text/plain (7bit)>]
> Toshihiro - I agree with many of your observations.
> 
> Please consider the attached proposal.  It includes an example to
illustrate
> the following policy:
> 
> "Recipient 1 is permitted access to Element 1, Element 2 and Element 3.
> Recipient 2 is
> permitted access to Element 1 and Element 2 only."
> 
> I feel certain some optimizations will be possible.  But, we have to make
> sure that we provide proper support for policies in which different
> recipients are permitted access to different portions of the message.
> 
> All the best.  Tim.

<snip>

--------------------------------------------------------------------------
--------------------------------------------------------------------------
<S:Envelope>
<S:Header>
<wsse:Security S:role="Recipient1">

  <ds:KeyInfo> !--Reference to Recipient1's key-agreement key
    <ds:X509Data>
      <ds:X509IssuerSerial>
        <ds:X509IssuerName>Issuer of Recipient1's
certificate</ds:X509IssuerName>
        <ds:X509SerialNumber>Serial number of Recipient1's
certificate</ds:X509SerialNumber>
      </ds:X509IssuerSerial>
    </ds:X509Data>
    <wsse:Reference URI="#a"/>
    <wsse:Reference URI="#c"/>
  </ds:KeyInfo>

  <xenc:EncryptedKey Id="a">
    <xenc:CipherData>
      <xenc:CipherValue>
        Key1 encrypted for Recipient1
      </xenc:CipherValue>
    <xenc:CipherData>
    <xenc:ReferenceList>
      <xenc:DataReference URI="#d"/>
      <xenc:DataReference URI="#e"/>
    </xenc:ReferenceList>
  </xenc:EncryptedKey>

  <xenc:EncryptedKey Id="c">
    <xenc:CipherData>
      <xenc:CipherValue>
        Key2 encrypted for Recipient1
      </xenc:CipherValue>
    <xenc:CipherData>
    <xenc:ReferenceList>
      <xenc:DataReference URI="#f"/>
    </xenc:ReferenceList>
  </xenc:EncryptedKey>

</wsse:Security>

!--

<wsse:Security S:role="Recipient2">

  <ds:KeyInfo> !--Reference to Recipient2's key-agreement key
    <ds:X509Data>
      <ds:X509IssuerSerial>
        <ds:X509IssuerName>Issuer of Recipient2's
certificate</ds:X509IssuerName>
        <ds:X509SerialNumber>Serial number of Recipient2's
certificate</ds:X509SerialNumber>
      </ds:X509IssuerSerial>
    </ds:X509Data>
    <wsse:Reference URI="#b"/>
  </ds:KeyInfo>

  <xenc:EncryptedKey Id="b">
    <xenc:CipherData>
      <xenc:CipherValue>
        Key1 encrypted for Recipient2
      </xenc:CipherValue>
    <xenc:CipherData>
    <xenc:ReferenceList>
      <xenc:DataReference URI="#d"/>
      <xenc:DataReference URI="#e"/>
    </xenc:ReferenceList>
  </xenc:EncryptedKey>

</wsse:Security>

</S:Header>
<S:Body>
<xenc:EncryptedData Id="d"/>
  <xenc:CipherData>
    <xenc:CipherValue>
      Element1 encrypted with symmetric Key1
    </xenc:CipherValue>
  </xenc:CipherData>
</xenc:EncryptedData>

<xenc:EncryptedData Id="e"/>
  <xenc:CipherData>
    <xenc:CipherValue>
      Element2 encrypted with symmetric Key1
    </xenc:CipherValue>
  </xenc:CipherData>
</xenc:EncryptedData>

<xenc:EncryptedData Id="f">
  <xenc:CipherData>
    <xenc:CipherValue>
      Element3 encrypted with symmetric Key2
    </xenc:CipherValue>
  </xenc:CipherData>
</xenc:EncryptedData>
</S:Body>
</S:Envelope>
--------------------------------------------------------------------------

You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php