OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[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 Signa tures



If the test CA happens to issue certificates without a basic
constraints attribute (not unheard of) then the attacker can
generate a chain:

  Test CA -> Test Cert -> 'Real CA' -> Phony Cert (serial num XX)

With this technique he can produce a certificate matching any
issuer name / serial number he wants.

The reference-resolving transform solves this problem.

Merlin

r/tim.moses@entrust.com/2003.06.17/15:20:11
>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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]