Re: PKCS 7/10 Security Issues

[Xiaoyi Liu <xliu@xxxxxxxxx>]

> 
> >Access to Public in PKCS 10 to validate message signature
> >---------------------------------------------------------
> >A point was raised that the only way one can implement the protocol is
> >through a modification of known toolkits in order to prove possession of
> >the private key.
> >
> >Proposed Resolution: To the contrary, the draft specifically proposes an
> >alternate mechanism that enables use of off-the-shelf components.  Working
> >within these constraints, a self-signed certificate is included in the
> >PKCSReq message.
> 
> Again, the slides would have helped you here.  I discussed this
> alternate mechanism and noted that this still doesn't work with existing
> toolkits.  Certainly the self-signed certificate allows the CA to get
> the public key without digging into the message content, but the CA has
> no reason to trust this key (because it can't possibly build a trust
> path from itself to this self-signed certificate).  Existing toolkits
> will therefore have to be modified to accept as valid a message signed
> with an untrusted key (a pretty undesirable situation). 

I just want to point out that, with Tipem 2.0, there is no need to modify the
existing toolkit. The self-signed certificate can be used to verify the 
signature, with the warning message from the toolkit. 

Generally, the key is untrusted in this case. That is why there is out of 
band user authentication. This protocol can also be extended to include 
the usage of pre-shared secret so the authentication can be in-band.

Xiaoyi
 [Furthermore,
> this is why Hemma's proposal for PKCS #10 DH won't work; the EE will not
> be able to construct a self-signed cert. using DH.]
> 
> 
> --------------------------------------------
> Carlisle Adams
> Entrust Technologies
> cadams@entrust.com
> --------------------------------------------
> 
> 
>