RE: CSPs and Certificate Extensions



The problem with this workaround for CPGetUserKey is that you don't really
know if the key will be used for signing or for key exchange. You really
shouldn't use the key for key wrapping. I agree with mounir that it's
probably safe to do that for CPSignHash - but would not recommend this for
CPGetUserKey.

Laszlo Elteto
SafeNet, Inc.

"Mounir IDRASSI" wrote:

Hi,

I'm not an expert on Word, but for me, this resembles to a bug in Word.
Unfortunately, such a behavior is not uncommon in Microsoft products (I have
seen it before on other MS components..).
One thing that people tend to do to overcome such limitations is to do the
following :
- When asked about an AT_SIGNATURE key in CPGetUserKey or CPSignHash,
return a handle to it if it exists or an error otherwise.
- When asked about an AT_KEYEXCHANGE key in CPGetUserKey or CPSignHash,
return a handle to it if it exists. If it doesn't exists, look for an
AT_SIGNATURE key on the same container. If this one exists, return a handle
to it. Otherwise, return an error.

As you can see, if you implement this approach inside your CSP, the Word
call to CryptSignHash will succeed because you'll use the AT_SIGNATURE key
internally even if he has specified AT_KEYEXCHANGE.
I know it's an ugly workaround but this is something that exists on
production CSPs on the market and I'm not aware of any other (cleaner)
approach.
Anyway, I hope this will help.

Cheers,
--
Mounir IDRASSI
IDRIX
http://www.idrix.fr

to reach : mounir_idrix_fr (replace the underscores with the at and dot
characters respectively)


"jantes" wrote:

Thank-you, that's a very, very useful tool and I can know see that the key
spec associated with the installed certificate in the "MY" store is correctly
set to AT_SIGNATURE. This matches the calls that are made to my CSP that I
can see in my log - CPGenKey with AT_SIGNATURE. As it is the Microsoft CA
that is making these calls, the source code isn't available to me, so I can't
match it up, but it all seems to make sense.

That means the problem is occurring when the certificate is being accessed -
in this case by Microsoft Word. When I try to sign a document using the
certificate it fails, and when I look in my log file I can see that a context
is acquired to the correct container, but after the data has been hashed,
CPSignHash is called with the key spec set to AT_KEYEXCHANGE. Again, I don't
have access to the source code that is actually making the CAPI calls, so I
can't see what's actually happening externally to my CSP.

On the surface it looks like when Word accesses the certificate to sign the
document it doesn't use the key spec associated with it - a bug in Word? Has
anyone else seen this behaviour, or have any suggestions on what could be
causing the problem? Or another test I could try that might resolve this?

Thanks in advance for any help you can give.
.