Continuing Encryption discussion - new proposal

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

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.