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

["Hal Lockhart" <hlockhar@bea.com>]

> -----Original Message-----
> From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM]
> Sent: Friday, June 13, 2003 7:48 PM
> To: Hal Lockhart; wss@lists.oasis-open.org
> Subject: RE: [wss] New Issue: Key Identifiers Should Not Be Used for
> Signatures
>
>
> A few points:
>
> 1. I agree with Hal on what the KeyIdentifiers should identify
>
> When I questioned KeyIdentifier before, the explanation I was given was
> that the "Key" part of key identifier didn't tell you *what* the
> identifier identified, but *how* the identifier identified.  Also the
> "Key" isn't a *cryptographic key* but more a *primary key* or *important
> data* kind of thing.  So KeyIdentifier is for identifying a security
> token (certificate, ticket, assertion, etc.) by some important
> primary-key kind of data in the security token.
>
> If we have profiles that identify security tokens by something that is
> not a primary key of the security token (and instead is only a primary
> key of the cryptographic key), we should try to minimize that as much as
> possible.

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.
+
>
> 2. Use of any kind of KeyIdentifiers with Signatures is okay
>
> It is not the Signature that introduces the security threat even if your
> KeyIdentifier only identifies the Key.  The Signature only takes you so
> far as the key to begin with.  The security threat comes if you apply a
> name claim or authorization claim based only on a Signature.  Before you
> apply a name or authorization claim you need to understand the semantics
> of the security token making that claim.  If the semantics of the token
> are that the name or authorization only applies in June, you need to
> consider that before you apply the claim.

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.

> 3. The security threat described in 2 exists no matter what the
> KeyIdentifier identifies
>
> If the KeyIdentifier only identifies the cryptographic key, the problems
> are as Hal outlines.  Even if they KeyIdentifier identifies the whole
> security token, typically the KeyIdentifier will not be included in the
> signature and so the KeyIdentifier can be changed to point to a
> different security token with the same cryptographic key and the
> signature will still validate.  The proper way to address the threat
> outlined in 2 is not to sign the KeyIdentifer but to do as described in
> 2 and understand the semantics of the security token before applying
> claims.

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?

Hal

>
> &Thomas.
>
> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Friday, June 13, 2003 3:03 PM
> To: wss@lists.oasis-open.org
> Subject: [wss] New Issue: Key Identifiers Should Not Be Used for
> Signatures
>
> As we discussed, the algorithm(s) for computing a Key Identifier is
> profile-specific. However, the one used in the Interop with X.509 certs
> is
> based only on the Public Key, not only any unique aspect of the
> certificate
> and I assume other profiles may do the same. Certainly the name suggests
> that the value identifies the Key and not the Certificate, Ticket or
> Assertion.
>
> It makes perfect sense to use such an identifier when sending encrypted
> data. Its only purpose is to indicate to the recipient which key of
> possibly
> several keys it knows, should be used to decrypt the data.
>
> However, using a key identifier to indicate the key to be used for
> signature
> validation creates an exposure to a certificate substitution. This has
> been
> discussed in past on the IETF PKIX list. Basically it is perfectly
> possible
> and legal for several certificates to exist which refer to the same key
> pair. Thus although the validation process succeeds, the associated
> identity
> information is in doubt. For example, a party could later disavow a
> signature by producing a certificate that contains usage constraints
> that
> were not met. Another possibility for confusion might occur if one
> certificate was revoked and the other was not, or they were revoked at
> different times.
>
> For this reason, when verifying a signature it is important for the
> signer
> to indicate not just the key, but the certificate to be relied on.
>
> Hal
>
>
> You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
> .php
>
>