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

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

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.

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.

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.

-----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