To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=78341
Issue #|78341
Summary|Digital Signature fails with certain PKI products
Component|xml
Version|680m140
Platform|PC
URL|
OS/Version|Windows, all
Status|UNCONFIRMED
Status whiteboard|
Keywords|
Resolution|
Issue type|PATCH
Priority|P3
Subcomponent|code
Assigned to|jl
Reported by|resnitzky
------- Additional comments from [EMAIL PROTECTED] Tue Jun 12 14:01:17 +0000
2007 -------
Certain PKI products cannot be used to digitally sign OOo documents on Windows.
The behavior observed by the user in OOo Writer is that after choosing File ->
Digital Signatures, then clicking Add, then choosing a certificate and clicking
OK => nothing happens: the certificate selection dialog is closed and the
Digital Signatures dialog is displayed with no signatures shown.
The problem has been reproduced with the following products:
- ARX CoSign client (using the ARX CryptoKit PKI middleware)
- Aladdin eToken (using the RTE 3.60 PKI middleware)
The issue manifests itself as a failure of the MS CAPI call
CryptAcquireCertificatePrivateKey called from the function
xmlSecMSCryptoKeyDataAdoptCert found in libxmlsec in the file
src/mscrypto/certkeys.c. GetLastError() returns 0x8009200B =
CRYPT_E_NO_KEY_PROPERTY = "The certificate doesn't have a private key property".
The reason for this failure is that the certificate context parameter passed in
the above call represents the certificate created by parsing the certificate
XML node by the function xmlSecMSCryptoX509CertificateNodeRead in the file
x509.c.
However, certificate contexts created from raw DER data using the CAPI call
CertCreateCertificateContext as is done here are *not* associated with the
private signing key and therefore fail the call to
CryptAcquireCertificatePrivateKey. The reason this seems to work with some PKI
products is that they *copy* the user's certificate from the signing device
into the MS Registry physical certificate store, and that 'helps' CAPI to
locate the signing key.
The affected products are those which implement a custom physical certificate
store to represent the certificates contained in the signing device. These
custom stores are registered under the "MY" system store collection along side
the MS Registry store (for more info on this architecture search Google
for "Logical and Physical Stores").
The signature should be done using the certificate context derived from
enumerating the "MY" store collection. This is already done by the code called
from xmlSecMSCryptoX509IssuerSerialNodeRead. When enumerating the "MY" store,
the association between the certificate context and the underlying signing key
is preserved.
Therefore the proposed patch is to simply ignore the call to
xmlSecMSCryptoX509CertificateNodeRead in the case of signing by adding the
following as the first line of code in xmlSecMSCryptoX509CertificateNodeRead:
if (keyInfoCtx->keyReq.keyType & xmlSecKeyDataTypePrivate) return 0;
An alternative solution is to change the certificate selection logic in the
function xmlSecMSCryptoX509StoreVerify in the file x509vfy.c so that in case of
signing the code will also make sure that the chosen certificate is associated
with a private key. A similar filter was implemented by CP in the function
SecurityEnvironment_MSCryptImpl::getPersonalCertificates in the file
xmlsecurity/source/xmlsec/mscryptsecurityenvironment_mscryptimpl.cxx.
Thanks,
- Uri
Uri Resnitzky
Chief Scientist, ARX
http://www.arx.com
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
