RE: [wss] Continuing Encryption discussion - new proposal

Title: 

Agh! I 
just realized the flaw in that proposal, Embedded is defined as a child of 
SecurityTokenReference, not of wsse:Security.

 

What I 
want is a way that I can reference the ds:X509IssuerSerial element in such a way 
that I can wrap a wsu:Id identifier either arround or into the 
element.

  
-----Original Message-----
From: Hallam-Baker, Phillip 
  [mailto:]
Sent: Monday, August 04, 2003 9:46 
  PM
To: 'Tim Moses'; 'NISHIMURA Toshihiro'; 
  
Subject: [wss] Continuing Encryption 
  discussion - new proposal

  
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.