WSS 1.1 questions chapter 8.5

["Granqvist, Hans" <hgranqvist@verisign.com>]

Title: WSS 1.1 questions chapter 8.5

See below for some WSS 1.1 questions from Apache developers. Any input welcome.

Thanks,
Hans


> ...
> I'm implementig the SignatureConfirmation feature of the
> upcoming 1.1. While doing so I have several questions/remarks about
> the text that defines SignatureConfirmation, chapter 8.5.  Can you
> forward the questions/statements to the appropriate list?
>
> Questions/statements:
>
> The text (chapter 8.5ff) always talks about: "every <ds:Signature>
> element that is a direct child of the <wsse:Security> header block in
> the originating message." . This may indicate there is only one
> <wsse:security> header per message. There may be many such blocks, each
> with a different actor/role of course. SignatureConfirmation has to be
> generated for every <wsse:Security> block if it contains <ds:Signature>?
>
> Because response messages can also contain more than one
> <wsse:Security> block: in which block to place the
> SignatureConfirmation? Can the SignatureConfirmation elements spread in
> several security blocks? Located in only one? Both ways allowed?
>
> My assumption during implementation:
> - generate SignatureConfirmation for every Signature of every
>   wsse:Security header
> - place all SignatureConfirmation elements together in one
>   wsse:Security header. This because it is not necessary that the
>   wsse:Security headers have a one-to-one relationship with
>   the request headers.
>
> In another part, the spec text states: "The responder MUST include all
> <wsse11:SignatureConfirmation> elements in the message signature of
> the response message(s)." . This sentence IMHO mandates that _every_
> response message must be signed, even responses to requests that did
> not contain a Signature. This requirement contradicts the previous
> usage of WSS: it is up to the responder if a message has to be signed,
> which part to sign etc.
>
> I can understand that if the responder decides
> to sign part(s) of the message then SignatureConfirmation elements
> could be signed as well. In this case however, which certifcate to use
> if there are several wsse:Security blocks with different actor/roles
> containing different Signature blocks that use different certificates?
> Handling is even more complicated different wsse:Security blocks
> handled by different receipients as stated in chapter 5: "a message MAY
> have multiple <wsse:Security> header blocks if they are targeted for
> separate recipients." .
>
> My assunption during implementation:
> - do not sign SignatureConfirmation in the very first step
> - in a second step: if signing SignatureConfirmation: sign it only if
>   the <wsse:Security> header that holds the SignatureConfirmation
>   elements also contains at least one ds:Signature. Include the
>   SignatureConfirmation elements in the first ds:Signature being
>   processed.
>
> A short statement about: "If the <ds:Signature> element corresponding
> to a <wsse11:SignatureConfirmation> element was encrypted in the
> original request message, the <wsse11:SignatureConfirmation> element
> SHOULD be encrypted for the recipient of the response message(s)."
> As the reason for this requirement it is stated: "..to protect the
> original signature and keys.". First of all, implementing this
> requirement puts quite a burden on the responder. Encrypting the
> SignatureConfirmation elements does not enhance security practically.
> Nothing else but the signature value is displayed: that is a random
> number for any malicious person. If we can't send this value in clear
> because this number would reveal information about "original signature
> and keys" then I would _never ever_ use a signature according to this
> standard. The signature value is an encrypted hash value - what is
> the security gain to encrypt it again?
> On a pratical side: which key to use to encrypt? The public key of the
> certificate used to sign parts of the request? I would not do so: it
> is well understood that key pairs (certificates) used to create
> signatures should not be used to perform encryption. For one good
> explanation see:
> www.washington.edu/computing/windows/issue22/encryption.html
>
> My assumption during implementation:
> - do not encrypt even if the Signature block of the request was
>   encrypted.
>
>
> Thanks in advance.
>
> Regards,
> Werner
>