Initial patch for parsing digitally signed PDFs NSS would be better than OpenSSL, and once all the p11-kit / NSS-shared-DB stuff gets figured out fully, then NSS-based apps will be able to access your gnome-keyring certificates via PKCS#11 chpe, KaL_out: both gnutls and glib-networking intentionally only do TLS, not crypto in general, so I don't think it makes sense to add the extra PKCS#7 functionality to either of them I wonder if it could be useful for glib-networking to implement the missing things in gnutls, or if we don't need that at all > Would it be a lot of work to add support for that to gnutls? > in PDF) as well as any optional timestamps or CRLs. > signed content (these are the essential parts for detached signatures as used > With openssl you can get the certificates, signature, and the digest of the
> and CRLs as you can confirm if you go through the functions that take > It seems that in gnutls they assume those objects can only contain certificates > PKCS#7 object as present in a PDF signature. > What's missing in gnutls is a way to parse all the relevant components of the I have no experience with gnutls or nss so if anyone can correct me or add something, feel free. being present or worse we'll need to introduce our own cert store. The disadvantage I see with nss is that we won't be able to reuse the system certificate store usually in /etc/ssl/certs because it will need to use a particular Berkeley DB cert store as you can find in your Firefox/Thunderbird Profile.
#UBUNTU PDF SIGNATURE CODE#
NSS seems to be more promising as I've found example code for PKCS#7 validation in its source tarball: mozilla/ security/ nss/cmd/ p7verify/ p7verify. I've only found this in the docs: org/software/ gnutls/ manual/ html_node/ X509-certificat e-API.html# X509-certificat e-API Gnutls seems to be unsuited for this because it doesn't have a decent PKCS7 API that would allow me to parse the signature and access each component.
the new functionality is not yet exposed in the qt4 wrapper as I prioritized the glib wrapper to support I can see the problem for poppler in terms of licensing. I've coordinated with Vasco Dias to expose this feature in Evince and his work is in the latest patches attached to this bug: Poppler_document_signature_get_signername the new functionality is not yet exposed in the qt4 wrapper as I prioritized the glib wrapper to support Evince. Timestamps contained in the PKCS7 signature are not verified cgi?id= 614929Īs the additional dependency on OpenSSL couldn't possibly satisfy everyone I made it optional at build-time with -enable-openssl for Autotools and -DENABLE_OPENSSL=ON for cmake I've coordinated with Vasco Dias to expose this feature in Evince and his work is in the latest patches attached to this bug: https:/ /bugzilla. Poppler_ document_ signature_ get_signername It uses OpenSSL PKCS7 API for the crypto operations (signature and certificate Validations).Ĥ new functions were added at the glib wrapper level:
#UBUNTU PDF SIGNATURE VERIFICATION#
This patch adds signature verification support to poppler core. Here's an initial attempt at solving this issue. What is recommended - storing the Object in the class or copy the string? I wasn't also sure I was freeing the memory correctly. I did not really understand the implications of choosing one over the other. Regarding the code related question: I have not been using poppler before and I noticed while looking at this that there was at least two ways of doing it. I think my initial idea was to have support in poppler to get only that is needed and then an application could implement the rest and later some of that could be refactored and moved back into poppler, but that's just and idea you know better how poppler works. And as Brad mentions the trusted root certificates might be fetched from some keystore integrated with the desktop. There are Gnutls, openssl and NSS and possibly other? I have not used any of them for this purpose (I am mainly a Java developer now days and normally use the Bouncy Castle API). However, I was not just sure if it is good to add a dependency to a particular crypto library. I can see you point that the verification should be included if all applications were to use it.
0 kommentar(er)
