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] New Issue: Key Identifiers Should Not Be Used for Signatures

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

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

> Specifically, we were given to understand that the Key Identifier
> by Microsoft and used in the Interop depends only on the value of the
> 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
> has not been modified since some unknown party generated it." Unless we
> 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

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

> Thomas is right, I didn't realize it, but the link from the signature to
> 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
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.


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

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