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

[Tim Moses <tim.moses@entrust.com>]

Colleagues - Unfortunately, there is no way for an authority to ensure that
a public key has not appeared in another certificate.  In fact, in a bridge
topology, it is essential that the same CA key appear in more than one
certificate.

An alternative solution is to include the certificate in the scope of the
signature.  Of course, this is equivalent to placing a digest of the
certificate in the SignedInfo.  But, we can describe this in a profile,
without impacting any schema.

All the best.  Tim.

-----Original Message-----
From: Rich Salz [mailto:rsalz@datapower.com]
Sent: Monday, June 16, 2003 9:52 PM
To: Hal Lockhart
Cc: wss@lists.oasis-open.org
Subject: RE: [wss] New Issue: Key Identifiers Should Not Be Used for
Signatures


> 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


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php