[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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]