Question

I sign document with PADES LTV Profile. Signer library is written base on Pdfbox library.

I have one problem.

In PADES LTV profile, the final revision must be checked in online (It means that OCSP responses, CRLS and certificates of this revision must not be in document secure store (DSS)).

For testing, I add 12 revision to my document.

Every time when I add new revision, I do not add certificates and ocsp responses of this current revision to the DSS. I add previous revisions certificates and ocsp responses to the DSS. I do this because last revision must be checked in online. So I must not add OCSP response of last revision to the DSS. I do so, but sometimes Adobe reader thinks that last revision have embedded OCSP response in the document.

The problem might be is that following:

Each ocsp response must be unique, even if when we generate them with the same certificate. In the other words, If we request ocsp object twice, they must be unique.

For this I do that following but it does not work:

private OCSPReq buildOcspRequest(X509Certificate issuerCert, BigInteger serialNumber, File inputDocument) {

    InputStream is = new FileInputStream(inputDocument);
    X509CertificateHolder certificateHolder;

    certificateHolder = new X509CertificateHolder(issuerCert.getEncoded());
    CertificateID id = new CertificateID(new BcDigestCalculatorProvider().get(CertificateID.HASH_SHA1), certificateHolder, serialNumber);

    OCSPReqBuilder ocspReqBuilder = new OCSPReqBuilder();
    ocspReqBuilder.addRequest(id);

    DigestCalculatorProvider digestCalculatorProvider;
    JcaDigestCalculatorProviderBuilder digestCalcProvBuilder = new JcaDigestCalculatorProviderBuilder().setProvider("BC");
    digestCalculatorProvider = digestCalcProvBuilder.build();

    // get SHA 256 
    DigestCalculator digest = digestCalculatorProvider.get(AlgorithmIdentifier.getInstance("2.16.840.1.101.3.4.2.1")); 

    OutputStream os = digest.getOutputStream();
    IOUtils.copy(is, os);

    byte[] messageImprint = digest.getDigest();

    BigInteger time = BigInteger.valueOf(System.currentTimeMillis());

    // time + imprint
    byte[] nonce = ArrayUtils.addAll(time.toByteArray(), messageImprint);

    Extension extension = new Extension(OCSPObjectIdentifiers.id_pkix_ocsp_nonce, true, nonce);
    ocspReqBuilder.setRequestExtensions(new Extensions(extension));

    return ocspReqBuilder.build();

}

this is testing pdf link SAMPLE PDF

I might create 4 revision and everything might be all right ... I don't know , sometimes it happens... When I was testing, the problem occours when I create many revisions... THE LAST REVISION THINKS THAT OCSP RESPONSE OF PREVIOUS REVISIONS IS IT'S OWN!

Was it helpful?

Solution

In PADES LTV profile, the final revision must be checked in online

No.

PAdES, i.e. ETSI TS 102 778, in part 4 (PAdES-LTV Profile) merely recommends this:

4.3 Validation Process

It is recommended that that validation process be as follows:

1) The "latest" document Time-stamp should be validated at current time with validation data collected at the current time.

The word should indicates a recommendation, and the sentence before actually spells it out.

But let's assume you want to follow the recommendation. Your interpretation

(It means that OCSP responses, CRLS and certificates of this revision must not be in document secure store (DSS)).

is not correct still: There may be validation related information (OCSP responses, CRLs, certificates) in the document which (seen as isolated information) apply to the outer time stamp or signature. If you time stamp your document twice in short succession using the same time stamp service and add a CRL for certificates used in the first time stamp in the time between, chances are that the outer time stamp involves certificates covered by this CRL and is applied in the validity interval indicated by the CRL.

No, it is the responsibility of the verifier not to use these information if the verifier chose to follow the PAdES-LTV recommendation quoted above.

Adobe Reader does not claim to follow this recommendation (at least as far as I know). Thus, if you verify the signatures and time stamps using Adobe Reader, information contained in the document may be used to verify the outer time stamp, too.

Actually Adobe originally loved the concept of first retrieving validation related information and signing and time stamping everything including those information thereafter.

The problem might be is that following:

Each ocsp response must be unique, even if when we generate them with the same certificate. In the other words, If we request ocsp object twice, they must be unique.

No. While it is good style to use nonces, your observation has nothing to do with them.

The reason why Adobe Reader sometimes (and only sometimes) makes use of already embedded information for verifying outer signatures / time stamps is that OCSP responses and CRLs have validity intervals defined by their thisUpdate and nextUpdate fields which sometimes (if you add multiple time stamps by the same TSA) in spite of being embedded for the validation of an older time stamp still encompass the time of the newly added one (and, thus, are also used for their validation).

If you want to prevent this, you have to check the OCSP responses and CRLs already contained in the PDF or just now added to it by you, inspect those whose respective validity interval has not yet ended, and not apply any time stamp to the document whose certificates can be validated with them.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top