1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
//! [`SealEnvelope`] — how a signature is packaged relative to its payload.
use ;
/// Where the seal sits relative to the bytes it covers.
///
/// # Why the port models both rather than choosing
///
/// A qualified seal **can** be a JWS signature: JAdES (ETSI TS 119 182-1) is an
/// AdES format built on RFC 7515, and its scope covers qualified electronic
/// seals explicitly. So "the seal is the payload's signature" and "the seal
/// wraps a digest of the payload" are both available at the standards layer, and
/// JAdES itself spans them — its `sigD` header identifies a detached payload
/// precisely because RFC 7515 has no native way to.
///
/// What decides which is available is **the provider's format menu, not the
/// law**. Those move independently, so a port that picked one would encode a
/// supplier's product decision as an architectural one. It is a capability.
///
/// # Not every packaging goes with every format
///
/// The values below are the union across all formats, and the union is not
/// meaningful on its own — the CSC API defines `signed_envelope_property` **per
/// signature format**, and the sets barely overlap. `Enveloping` is an XAdES
/// packaging; `Certification` and `Revision` are PAdES revisions and mean
/// nothing elsewhere. Which ones a given format admits is
/// [`SealFormat::envelopes`](crate::seal::SealFormat::envelopes), and [`SealCapabilities::can_produce`](crate::seal::SealCapabilities::can_produce) rejects a
/// pair no format defines.