RE: [wss] New Issue: Key Identifiers Should Not Be Used for Signatures

[Rich Salz <rsalz@datapower.com>]

> Specifically, we were given to understand that the Key Identifier generated
> by Microsoft and used in the Interop depends only on the value of the Public
> Key in the Certificate. Although, its value appears in the certificate in
> the SubjectKeyIdentifier extension, presumably two certificates containing
> the same Public Key would have the same value.

This seems pretty standard.  It's a subject Key identifier, after all,
not a subject cert identifier.  If you look at the PKIX RFC, and probably
go back to X509, that's what it says.  The common default for SKI, barring
some out-of-band means to identify, is SHA1 hash of the DER of the key.

> But there is no other use for a signature! It is pointless to say "This data
> has not been modified since some unknown party generated it." Unless we have
> some information about some attribute of the signer, the signature is
> useless. If all we know is the key, we have nothing to base our actions on.

I believe it optimizes for the common case where most parties have one
certificate per key.  It seems unwise to have the same keypair certified
for different uses.

If you are worried about the signer's identity beyond the key then I
believe that the correct approach is to bind that identity into the
signature.

> Thomas is right, I didn't realize it, but the link from the signature to the
> token is in KeyInfo which appears in <Signature> but not in <SignedInfo>.
> This looks like a huge hole to me. Can somebody tell me I am wrong?

Huge seems overstating; I'd say minor, if any adjective is called for at all.
How many times do you get the same keypair certified
for different uses?  Common practice says to have separate keys for signing
and encryption, even.

        /r$

--
Rich Salz                  Chief Security Architect
DataPower Technology       http://www.datapower.com
XS40 XML Security Gateway  http://www.datapower.com/products/xs40.html
XML Security Overview      http://www.datapower.com/xmldev/xmlsecurity.html