Continuing Encryption discussion - new proposal

Title: 

OK, now that I have finally got XKMS of my mind and I don't have 
to context switch. sorry to reopen this one but I think we can meet some of the 
issues being raised in a cleaner fashion.

Currently the encryption 
example 
starts:

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

I agree we need a separate role for each actor by the 
SOAP processing rules. However I have a big problem with the way that 
wsse:Reference is being used here. I do not find descriptive text in the core 
draft that says that it can be used to create what is in effect an ad-hoc 
forward reference from a ds:KeyInfo segment.

Taking a step back we have 
to include an option for direct reference to a certificate by means of 
BinarySecurityToken to meet Hal's interop issue. This means that the keyinfo 
processing gets out of whack. I certainly do not want to end up inventing a 
binary equivalent of the same thing.

What I propose is that instead of 
using KeyInfo as specified we instead use the wsse:embedded token. That means 
that the above example will instead start as 
follows:

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

  <wsse:Embedded 
wsu:Id="Recipient1Key"
      
<ds:X509IssuerSerial>
        
<ds:X509IssuerName>Issuer of R1's 
crt</ds:X509IssuerName>
        
<ds:X509SerialNumber>Serial number of R1's 
crt</ds:X509SerialNumber>
      
</ds:X509IssuerSerial>
  </wsse:Embedded>

Note that 
X509IssuerSerial is the only element specified as a child of wsse:Embedded in 
the X.509 profile, other profiles could pick out other pieces of data.

If 
we go this route I believe that the rest of Tim and Toshihiro's discussion is at 
that point applicable to the subject of WS-Security generally and is in no way 
specific to the X.509 profile and I therefore propose to drop that text from the 
profile. We should revist the issue of whether core meets the relevant 
criteria.

The intro on token types is then modified to include the 
following text:

In order to ensure a 
consistent processing model across all the token types supported by WS-Security, 
the wsse:SecurityTokenReference element SHOULD be used to specify all references 
to X.509 token types in signature or encryption elements.

A 
wsse:SecurityTokenReference MAY reference an X.509 token type by one of the 
following means:

Key Identifier
The wsse:SecurityTokenReference element contains a 
wsse:KeyIdentifier element that specifies the token data by means of a URI 
reference.

Reference to a Binary Security Token
The 
wsse:SecurityTokenReference element contains a wsse:Reference element that 
references a wsse:BinarySecurityToken element that contains the token data 
itself.

Reference 
to a Embedded Issuer and Serial Number
The wsse:SecurityTokenReference 
element contains a wsse:Reference element that references a wsse:Embedded 
element which contains a ds:X509IssuerSerial element that uniquely identifies an 
end entity certificate.

I notice that currently the examples use KeyName instead of 
security token reference to make this connection. I will fix 
this.