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

[Tim Moses <tim.moses@entrust.com>]

Merlin - This IS to do with repudiation.  It is a "first-party" attack ...

The Subscriber has two signature-verification certificates for the same key.
One is valid for live transactions, and the other isn't.  Perhaps, it is
clearly marked "for test purposes only".  He signs the transaction with the
key and attaches the first certificate.  This is accepted by the Relying
Party, which then commits resources.  The Subscriber subsequently wishes to
repudiate and claims that he attached the second certificate.  Perhaps, the
Subscriber has used the first certificate in other transactions with this
Relying Party, so Subscriber's explanation is that Relying Party substituted
the certificate that is valid for the transaction in place of the "test"
certificate.

Maybe you can argue that the Subscriber must have had something nefarious in
mind when he got the same key certified both ways.  Nevertheless, it should
be a simple matter to eliminate the uncertainty by referencing the attached
certificate by issuer/serial and including the reference in the scope of the
signature, as CMS does.

All the best.  Tim.

-----Original Message-----
From: merlin [mailto:merlin@baltimore.ie]
Sent: Tuesday, June 17, 2003 3:04 PM
To: Tim Moses
Cc: wss@lists.oasis-open.org
Subject: Re: [wss] New Issue: Key Identifiers Should Not Be Used for
Signa tures 



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