How to validate an ASiC-E container (step by step)

Validating an ASiC-E container means confirming three things: it's actually an ASiC-E ZIP and not a generic archive, every data file inside matches the digest its signature claims for it, and the signature itself resolves — chain, revocation, timestamp — the same way any CAdES or XAdES signature does. The container format decides how you get from "here's a ZIP" to "here's a signature," and that path differs depending on which inner signature type it holds.

ASiC-E (ETSI EN 319 162) is a ZIP that bundles one or more data files with one or more signatures over them, wrapped in a fixed internal layout. It's the multi-file counterpart to ASiC-S, which holds exactly one data object. Everything below applies to .asice files specifically — a plain PDF or a standalone XAdES file doesn't go through any of this.

What's actually inside the ZIP

Three things, always in this arrangement:

• mimetype — the first entry in the archive, stored uncompressed. Its content is the literal string application/vnd.etsi.asic-e+zip. Storing it first and uncompressed means a reader can identify the container from the first bytes of the ZIP, without inflating anything.
• META-INF/ — holds the signature file(s) and, for one of the two inner formats, a manifest.
• The data files themselves — sitting at the ZIP root alongside META-INF/, exactly as the signer added them.

That's the whole container. Everything about validating it comes down to what's inside META-INF/.

Two inner signature formats, two integrity paths

ASiC-E allows either XAdES or CAdES as the inner signature, and the two take different routes to the same guarantee.

XAdES inside ASiC-E. The signature lives in META-INF/signatures001.xml (numbered from there if a second, independent signature exists). Each ds:Signature element carries its own ds:Reference entries pointing directly at the data files by name. That means integrity is a direct check: recompute the digest of each referenced file, compare it to the value in the reference, done. No intermediate document to reason about — the signature's own references are the manifest.

CAdES inside ASiC-E. CMS has no concept of referencing a file by name inside the archive, so ASiC-E adds one: META-INF/ASiCManifest.xml. This manifest lists every covered data file with its digest and MIME type, and the CAdES signature (META-INF/signature001.p7s) signs the *manifest*, not the data files directly. Integrity here is two steps, not one: confirm each file's digest against the manifest entry, then verify the CAdES signature over the manifest bytes. If the manifest and the files agree but the CAdES signature over the manifest fails, the whole thing is still invalid — the manifest is just a lookup table, not proof of anything on its own.

Both routes end at the same four checks that apply to any CAdES or XAdES signature: integrity (as above), certificate chain, revocation, and timestamp — with the same baseline levels (B, T, LT, LTA) deciding which of those resolve from embedded data versus a live lookup.

Order matters, same as any other format

Integrity has to resolve first, per signature, before chain or revocation mean anything. For a CAdES-signed container that means: check the file digests against the manifest, then check the manifest's signature — only after both hold does it make sense to build the certificate chain. A manifest digest mismatch caps the result immediately; there's no reason to go further and check whether the issuing certificate is on an EU trusted list.

Multiple files, multiple signatures

ASiC-E doesn't cap either dimension. A single container can hold five data files and two independent signatures, where each signature's manifest (or reference set, for XAdES) covers a different subset of those files — one party signing three of the five, another signing all five. Validating this correctly means enumerating every signature file in META-INF/ first, then resolving each one's coverage independently. A signature that covers three files says nothing about whether the other two are signed by anyone; report coverage per signature, not one pass/fail for the archive.

Validating it in one call

Sealium's engine detects the container from the ZIP structure and mimetype entry, determines whether the inner signature is XAdES or CAdES, and runs the matching path automatically — you don't declare the format:

``bash curl -X POST https://api.sealium.eu/v1/validate \ -H "Authorization: Bearer slm_live_xxxxxxxxxxxxxxxxxxxx" \ -F "file=@contract-bundle.asice" ``

The report identifies the container and each signature inside it:

``json { "format": "ASiC-E", "signaturesCount": 2, "validSignaturesCount": 2, "signatures": [ { "signatureId": "id-abc123", "signatureFormat": "CAdES_BASELINE_LT", "coveredFiles": ["invoice.pdf", "annex-a.xml", "annex-b.xml"], "signatureIntact": true, "certValid": true, "revocationOk": true, "timestampValid": true, "indication": "TOTAL_PASSED" }, { "signatureId": "id-def456", "signatureFormat": "XAdES_BASELINE_T", "coveredFiles": ["invoice.pdf"], "signatureIntact": true, "certValid": true, "revocationOk": true, "timestampValid": true, "indication": "TOTAL_PASSED" } ] } ``

coveredFiles is the manifest (for CAdES) or the reference set (for XAdES), resolved into plain filenames either way — you don't need to know which inner format produced it to read the result. The document itself is processed in memory and never stored; only this report is persisted. Full field definitions, including the nested certChain and timestamps arrays that apply per signature, are in the API reference. Free tier: 100 validations a month, no credit card.

FAQ

Does an ASiC-E container always use the same inner signature format for every signature inside it? No. A container can mix XAdES and CAdES signatures, each covering its own subset of files via its own reference set or manifest. Validate each signature according to its own signatureFormat — don't assume the whole archive is one format because the first signature is.

What happens if a data file listed in the manifest is missing from the ZIP? The signature can't resolve — there's no file to hash and compare against the manifest's digest entry. This reports as a failed or indeterminate result for that signature rather than being silently skipped, since a missing covered file is exactly the kind of tampering the manifest exists to catch.

Is ASiC-E validation different from validating the CAdES or XAdES signature on its own? The four post-integrity checks — chain, revocation, timestamp — are identical to standalone CAdES or XAdES validation. The difference is entirely in how integrity is established: standalone XAdES references its data directly, standalone CAdES is typically detached with an external reference already known to the verifier, but ASiC-E's CAdES path adds the manifest as an extra indirection layer specifically so the container can hold more than one file under one signature.

Can I tell from the file extension alone whether a container is ASiC-E or ASiC-S? Not reliably — both are ZIP files and some tools use .asice/.asics extensions while others leave them as .zip. The mimetype entry inside the archive is the authoritative signal, which is why format detection reads the container's internals rather than trusting the filename.