Extending signature to XAdES-A form fails

[GoogleCodeExporter]

Library doesn't support extending previous forms to -A form.

Since in Issue 55 we have support for both creation and validation of XAdES up 
to and including X-L form, full support for A form is possible.


Attached patches add basic support for -A form, missing features:
 - lack of support for adding next ArchiveTimeStamps after the initial one
 - no support for TimeStampValidationData property (both creation and use)
 - no tests with lapsed Signature or TimeStamp certificates (see issue 55, patch 0011-test-XAdES-X-L-form-with-minimal-trust-anchors for example tests)

Patches *depend* on patches from issue 55!

Original issue reported on code.google.com by [email protected] on 16 Dec 2012 at 9:22

Attachments:

• 0001-add-tests-for-basic-A-form.patch
• 0002-add-support-for-validating-ArchiveTimeStamp-property.patch
• 0003-Align-implementation-with-version-1.4.2-of-the-stand.patch
• 0004-update-form-checker-to-XAdES-A-support.patch
• 0005-add-ArchiveTimeStamp-unmarshaller.patch
• 0006-add-ability-to-extend-X-L-form-to-basic-A-form.patch

[GoogleCodeExporter]

Patches add preliminary support for full -A form, including 
TimeStampValidationData property.

Implemented features:
 - support for TimeStampValidationData property, both creation and use for validation
 - test suite with lapsed time stamps and certificates (including CA)

Missing features:
 - lack of support or tests with multiple A time stamps
 - every added TimeStampValidationData contains *all* revocation data for TimeStamps, including data already included before

patches 1-6 are the same as in main issue entry

Original comment by [email protected] on 18 Dec 2012 at 4:44

Attachments:

• 0001-add-tests-for-basic-A-form.patch
• 0002-add-support-for-validating-ArchiveTimeStamp-property.patch
• 0003-Align-implementation-with-version-1.4.2-of-the-stand.patch
• 0004-update-form-checker-to-XAdES-A-support.patch
• 0005-add-ArchiveTimeStamp-unmarshaller.patch
• 0006-add-ability-to-extend-X-L-form-to-basic-A-form.patch
• 0007-allow-for-the-validation-of-timestamp-to-change-time.patch
• 0008-add-XAdES-A-tests-with-past-timestamps.patch
• 0009-add-note-about-grace-time-and-verification.patch
• 0010-add-TimeStampValidationData-property.patch
• 0011-add-support-for-XAdES-1.4.1-ValidationDataType.patch
• 0012-unmarshalling-of-TimeStampValidationData-property.patch
• 0013-add-ValidationData-property-structure-verifier.patch
• 0014-add-TimeStampValidationData-verifier.patch
• 0015-emphisise-that-TimeStampValidationData-is-from-1.4.1.patch

[GoogleCodeExporter]

continuing comment 1, rest of patches (all)

Original comment by [email protected] on 18 Dec 2012 at 4:46

Attachments:

• 0016-add-TimeStampValidationData-marshaller.patch
• 0017-TimeStampValidationData-property-generator.patch
• 0018-allow-for-adding-TimeStampValidationData.patch
• 0019-add-test-for-creation-and-consumption-of-TimeStampVa.patch
• 0020-add-support-for-A-form-properties-to-ArchiveTimeStam.patch
• 0021-add-simple-test-for-TimeStampStampValidationData-pro.patch
• 0022-align-ValidationDataType-with-version-1.4.2-of-stand.patch
• 0023-update-old-unmarshaller.patch

[GoogleCodeExporter]

I've fixed the "lack of support or tests with multiple A time stamps" problem, 
I'll release the code once I'll fix the problem with the ever growing 
TimeStampValidationData (probably in next 2 days)

Original comment by [email protected] on 19 Dec 2012 at 5:49

[GoogleCodeExporter]

Patches posted above (01-23) stay as-is. Rest is attached to this and following 
comments.

This patch series fix all problems related to creation and verification of 
XAdES-A form:
 - support for multiple T, X, A timestamps from different TSAs
 - support for extending A form to A form
 - support for validating any number of subsequent ArchiveTimeStamps (tests with series of 4 time stamps extended over 20 year period, including lapsed CAs)
 - creation of minimal TimeStampValidationData property (no duplication of certificates and CRLs between different TimeStampValidationData or XAdES-X-L properties)
 - preliminary support for grace period (full support won't be added because of lack of support from Bouncy Castle or Java), CRLs are added to TimeStampValidatoinData only if they were published after the time in time stamp they're protecting plus a week

Original comment by [email protected] on 27 Dec 2012 at 5:20

Attachments:

• 0024-fix-message-in-AgedTimeStampTest.patch
• 0025-add-test-for-A-TimeStamping-already-A-TimeStamped-do.patch
• 0026-add-support-for-A-timeStamping-already-A-timeStamped.patch
• 0027-don-t-require-optional-properties-in-ArchiveTimeStam.patch
• 0028-add-support-for-creating-multiple-timeStamps-of-T-an.patch
• 0029-save-validation-data-with-time-stamp-property.patch
• 0030-clean-up-SurrogateTimeStampTokenProvider.patch
• 0031-update-JavaDocs-to-reflect-support-for-XAdES-A.patch
• 0032-make-certs-and-CRLs-saved-in-properties-unique.patch
• 0033-add-only-non-duplicated-data-to-A-VD-form.patch
• 0034-consider-parameters-individually-in-tsValDataProp.patch
• 0035-don-t-assume-presence-of-data-in-TSValData-property.patch
• 0036-don-t-try-to-create-empty-TSVerData-property.patch
• 0037-remove-verifyAextendAVD-test.patch

[GoogleCodeExporter]

rest of patches.

This closes the issue.

Original comment by [email protected] on 27 Dec 2012 at 5:26

Attachments:

• 0038-update-AgedTimeStampTest-for-new-TSValData-creator.patch
• 0039-fix-subCA-cert-creation.patch
• 0040-realistic-tests.patch
• 0041-fix-variable-names-in-PropertiesUtils.patch
• 0042-clean-imports-and-add-code-comments.patch
• 0043-add-validation-data-before-validating-all-properties.patch
• 0044-don-t-fail-windows-only-tests-on-non-windows-platfor.patch

[GoogleCodeExporter]

To ease download, all patches in single file.

Original comment by [email protected] on 27 Dec 2012 at 5:27

Attachments:

• xades-a-support.zip

[GoogleCodeExporter]

There is a major issue with validation of the A from.
It fails for enveloping signature because of not correctly implementing XAdES 
v1.4.2 specification clause G.2.2.16.2.4, point 1) of particular rules for 
implicit mechanism.
Here's a patch fixing the problem, to be applied on top of aforementioned 
patches.

Original comment by [email protected] on 24 Jul 2013 at 1:44

Attachments:

• 0045-fix-validation-bug.patch

[tomato42]

fyi: while I ([email protected]) don't work on XAdES any more, I'm still very much active in the crypto space, and if there are some questions about this patch set (or the use-case it was supposed to solve), I will do my best to answer them 😃

[luisgoncalves]

Thanks @tomato42!

Actually, can you try to recap the use-cases you had back then?

• Which form do you start with?
• Are you adding multiple SignatureTimeStamp (XAdES-T). And after that, are you going straight to XAdES-A?
• Do you have interoperablity scenarios (validation by other tools)?

Thanks.

[tomato42]

Which form do you start with?

we started with XAdES-T (really XAdES-BES, but the timestamp was being added right away, still on the user's workstation, before document ingestion by the document management system)

Are you adding multiple SignatureTimeStamp (XAdES-T)

the plan was to add a second timestamp quite quickly (within 24h) to protect against CA compromise and keep at least 2 independent timestamps valid at any one time

And after that, are you going straight to XAdES-A?

no, and it's not possible – Polish law allows the qualified CAs up to a week (IIRC, don't quote me on that, it was 5 years ago I last read it :) to publish up to date CRL data, so to create XAdES-X we have to wait multiple days after creation of XAdES-C, only after that grace period elapses, the document can be timestamped in a XAdES-X document.

in other words: the CRL/OCSP is not considered valid until it was published at least a week (IIRC) after the signature was created (according to the timestamp)

it is to protect against a situation in which the HSM is stolen and quickly used to create (technically) forged documents, and CA includes the the key-compromise date in the CRL (but at the same time, the CA doesn't have a requirement to keep the information about certificate revocation after the signing certificate would expire naturally so the CRL can't be too old either)

(yes, it's quite complex, I hope I made myself clear... 😕 )

I don't know what was the actual period after which the XAdES-A was being created after that, I wasn't working on the deployment. But given that the system was designed with qualified signatures in mind and the qualified timestamps aren't exactly cheap, all the timestamping definitely was being stretched as much as possible (so you can expect that a second timestamp from the same CA wouldn't be used earlier than 1-2 months before the old one was scheduled to expire).

Do you have interoperablity scenarios (validation by other tools)?

we didn't have at the time, but I don't know if it didn't change – the signatures were on data-exchange documents so requiring them to be verifiable by other tools wouldn't be too out of place...

[luisgoncalves]

Thanks for the feedback @tomato42!