WSS 1.1 questions chapter 8.5

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

>