Workaround implemented regarding a bug with RFC2253 names where RDNs were not resolved at signing time (resulting from a BKU that could not resolve the respective OIDs):

e.g.  2.5.4.5=#1306323030383034,CN=Foreigner CA,C=BE

The example shows a RDN "2.5.4.5" which should have been resolved to "serialNumber" at signing time.

Imagine a line break between "Foreigner" and "CA" within the signature block. After text extraction the Name looks like as follows:

2.5.4.5=#1306323030383034, CN=ForeignerCA,C=BE

We recognize that the name shows spaces prior to RDNs and that the space between "Foreigner" and "CA" is missing due to text extraction/reconstruction. The naive approach would be to take the complete RFC2253 name from the certificate, since that name has also been used for signature. But this does not work in some cases because while the BKU was not able to resolve 2.5.4.5 on signing time, the entity invoking pdfas for verification might be at verification time, so that taking the name from certificate on verification time, may not result in the name we had at signing time.

This workaround merges information from text extraction with information from the certificate. The method takes all RDNs from the extracted text and merges them with the values from the certificate (considering the case where the textual version shows BER encoded values (e.g. <code>#1306323030383034</code>).

git-svn-id: https://joinup.ec.europa.eu/svn/pdf-as/trunk@665 7b5415b0-85f9-ee4d-85bd-d5d0c3b42d1c

0 files changed, 0 insertions, 0 deletions