Re: [wss] New Issue: Key Identifiers Should Not Be Used for Signa tures

[merlin <merlin@baltimore.ie>]

Maybe I am misunderstanding the issue.

As far as I can tell, an attack has been proposed whereby a
document is signed with a private key, and is presented along
with a reference to some valid (i.e. trusted CA, appropriate
usage, non-revoked, etc.) certificate. At a later point, by
virtue of an ambiguity in the reference, an attacker presents
an alternative certificate instead. Surely, in order for this
attack to succeed, the alternative certificate must be valid
(i.e. trusted CA, appropriate usage, non-revoked, etc.) and
therefore the attack is tantamount to sending the request with
the alternate certificate in the first place.

That is to say, if the substitute certificate is valid (and
the attack is moot if it is not), and it could therefore have
been used when the request was first made, what is the attack?

If this has to do with repudiation (sender claims they 'used'
a different cert that wasn't valid), then the recipient must
have archived the validation/authorization steps that it
performed and can present this evidence.

Finally, we have agreed that signing token references is
insufficient and have defined a transform that resolves
references during signature processing and replaces them with
the resulting data; this transform will solve the problem,
whether subject key identifiers or anything else is used,
as far as signing the actual security tokens used in a
cryptographic operation.

I agree that SKID may resolve to more than one certificate;
however, I'm just not convinced that this leads to a meaningful
attack. Ambiguity, yes; solved by issuer name/serial number
as you say.

Merlin

r/tim.moses@entrust.com/2003.06.17/14:26:33
>Merlin - CMS references certificates by issuer/serial.  One of the reasons
>for this is that (as Hal points out) a key may be valid, but only for
>certain purposes, as indicated by its certificate policy identifiers.  An
>X.509 certificate does more than bind a name and a key independent of usage.
>The CMS approach works provided CAs use a different serial number in every
>certificate they issue.  We should follow their example.  All the best.
>Tim.
>
>-----Original Message-----
>From: merlin [mailto:merlin@baltimore.ie]
>Sent: Tuesday, June 17, 2003 11:47 AM
>To: Hal Lockhart
>Cc: wss@lists.oasis-open.org
>Subject: Re: [wss] New Issue: Key Identifiers Should Not Be Used for
>Signatures 
>
>
>r/hlockhar@bea.com/2003.06.17/10:06:12
>>The problem is that the Relying Party has know way of knowing how many
>>certificates the sender has. At a minumum I would say this makes the spec
>>totally useless for non-repudiation purposes and even doubtful for ordinary
>>Authorization.
>
>I think that this certificate substitution attack is no
>different from the attack of submitting the initial request
>with certificate B (same key) instead.
>
>The recipient trusts certain CAs, presumably based upon
>their security policies. If one of the CA/PKI systems asserts
>that an identity/key binding is valid, the requestor proves
>ownership of the key, and the identity is sufficient for the
>recipient to authorize the request, then the request will
>be processed. It is up to the recipient not to accept certs
>issued by CAs that don't have adequate security policies.
>
>Merlin


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com