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: Re: [wss] Issue 104: Signature Transform


r/tim.moses@entrust.com/2003.07.03/15:45:14
>Merlin - The thing that doesn't quite seem to all line-up yet is this ...
>
>Your transform operates on "the input node set" (presumably the resource
>identified in the enclosing ds:Reference element).  At least according to
>the example in Section 8.5 of the June 30th version of the core
>specification, the token is not referenced here and so does not form part of
>"the input node set".
>
>If this is the case, something has to change.  Right?

Hi Tim,

I'm not sure I understand.. The key information has to be
explicitly signed in order for the transform to have any
effect. Example 8.5 would need a new reference:

  <ds:Reference URI="#key-info">
    <ds:Transforms>
      <ds:Transform Algorithm="&deref;">
        <ds:CanonicalizationMethod Algorithm="&exc-c14n;" />
      </ds:Transform>
    </ds:Transforms>
    ...
  </ds:Reference>
  ..
  <ds:KeyInfo Id="key-info">
    <wsse:SecurityTokenReference>
      <wsse:Reference URI="#X509Token" />
    </wsse:SecurityTokenReference>
  </ds:KeyInfo>

In this case, what would be signed would not be the
literal key information you see there, but instead:

  <ds:KeyInfo Id="key-info">
    <wsse:BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary" wsu:Id="X509Token">
                 MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
  </wsse:BinarySecurityToken>
  </ds:KeyInfo>

merlin

>All the best.  Tim.
>
>-----Original Message-----
>From: merlin [mailto:merlin@baltimore.ie]
>Sent: Tuesday, July 01, 2003 10:29 AM
>To: wss@lists.oasis-open.org
>Subject: [wss] Issue 104: Signature Transform
>
>
>
>Here's rough text of my proposed dereferencing transform:
>
>. Transform Algorithm URI:
>
>The algorithm is identified by the URI: &foo;dereference
>
>. Transform Input:
>
>The input is a node set. If the input is an octet stream, then
>it is automatically parsed; cf. dsig.
>
>. Transform Output: 
>
>The output is an octet steam. 
>
>. Syntax:
>
>The transform takes a single mandatory parameter, a
>ds:CanonicalizationMethod, which is used to serialize the input
>node set. Note, however, that the output may not be strictly in
>canonical form, per the canonicalization algorithm; however, the output
>is canonical, in the sense that it is unambiguous.
>
>. Processing Rules:
>
>Let N be the input node set.
>
>Let R be the set of all wsse:SecurityTokenReference elements
>in N.
>
>For each Ri in R, let Di be the result of dereferencing Ri.
>
>  If Di cannot be determined, then the transform MUST
>  signal a failure.
>
>  If Di is an XML security token, then let Ri' be Di.
>
>  Otherwise, Di is a binary security token. In this case, let
>  Ri' be a node set consisting of a wsse:BinarySecurityToken
>  element, utilizing the same namespace prefix as the
>  wsse:SecurityTokenReference element Ri, with no EncodingType
>  attribute, a ValueType attribute identifying the content
>  of the security token, and text content consisting
>  of the binary-encoded security token, with no whitespace.
>  The ValueType QName MUST use the same namespace prefix as
>  the BinarySecurityToken element if the QName has the same
>  namespace URI. Otherwise, it MUST use the namespace prefix
>  x. If no appropriate ValueType QName is known, then the
>  transform MUST signal a failure.
>
>Finally, employ the canonicalization method specified as a
>parameter to the transform to serialize N to produce the
>octet stream output of this transform; but, in place of any
>dereferenced wsse:SecurityTokenReference element Ri and
>its descendants, process the dereferenced node set Ri'
>instead. During this step, canonicalization of the replacement
>node-set MUST be augmented as follows:
>
>* A namespace declaration xmlns="" MUST be emitted with every
>  apex element that has no namespace node declaring a value
>  for the default namespace; cf. XML Decryption Transform.
>
>* If the canonicalization algorithm is inclusive XML canonicalization
>  and a node-set is replacing an element from N whose parent
>  element is not in N, then its apex elements MUST inherit
>  attributes associated with the XML namespace from the parent
>  element., such as xml:base, xml:lang and xml:space.
>
>----------------
>
>
>----------------------------------------------------------------------------
>-
>The information contained in this message is confidential and is intended
>for the addressee(s) only.  If you have received this message in error or
>there are any problems please notify the originator immediately.  The 
>unauthorised use, disclosure, copying or alteration of this message is 
>strictly forbidden. Baltimore Technologies plc will not be liable for
>direct, special, indirect or consequential damages arising from alteration
>of the contents of this message by a third party or as a result of any 
>virus being passed on.
>
>This footnote confirms that this email message has been swept for Content
>Security threats, including computer viruses.
>http://www.baltimore.com
>
>
>You may leave a Technical Committee at any time by visiting
>http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php
>
>You may leave a Technical Committee at any time by visiting http://www.oasis-o
>pen.org/apps/org/workgroup/wss/members/leave_workgroup.php
>


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com



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