| 37 |
37 |
verifiers. The certificates have the following properties:
|
| 38 |
38 |
* Selective disclosure of content.
|
| 39 |
39 |
* Proofs on attributes contained in certificates.
|
| 40 |
|
* Unlinkability between certificate issuing and showing transactions.
|
|
40 |
* Unlinkability between certificate issuance and transaction disclosure.
|
| 41 |
41 |
|
| 42 |
42 |
The Cryptic library can be used to create at a low-level certificates with the
|
| 43 |
43 |
properties previously enumerated. The certificate formatting, in XML or ASN1
|
| ... | ... | |
| 45 |
45 |
|
| 46 |
46 |
The goal is a fine-grained information disclosure for off-line certificates.
|
| 47 |
47 |
Such certificates may be used multiple times without re-issuing. When a
|
| 48 |
|
certificate is issued on demand, it is trivial to make it includes only the
|
|
48 |
certificate is issued on demand, it is trivial to make it include only the
|
| 49 |
49 |
needed information. However, when the certificate is already issued, it is
|
| 50 |
50 |
useful to have means to select which signed information is revealed. For
|
| 51 |
51 |
instance, the selective disclosure allows to reveal a date of birth and not a
|
| ... | ... | |
| 54 |
54 |
birth contained in the certificate.
|
| 55 |
55 |
|
| 56 |
56 |
A certificate is said 'proved' because a secret is included in the
|
| 57 |
|
certificate. To only show a certificate require to prove to verifier that the
|
| 58 |
|
secret is known without revealing it. (It is similar to prove the knowledge of
|
| 59 |
|
a private key making a signature. In a way, the public key is proved as a
|
|
57 |
certificate. To only show a certificate require to prove to the verifier that
|
|
58 |
the secret is known without revealing it. (It is similar to prove the knowledge
|
|
59 |
of a private key making a signature. In a way, the public key is proved as a
|
| 60 |
60 |
certificate is proved.)
|
| 61 |
61 |
|
| 62 |
62 |
Certificate holder is a term usually avoided because it may refer to bearer
|
| 63 |
|
tokens. Holder may be used if it is taken as a synomous to know the secret of
|
| 64 |
|
the certificate hold.
|
|
63 |
tokens. Holder may be used if it is taken as synonymous to knowing the secret
|
|
64 |
the certificate holds.
|
| 65 |
65 |
|
| 66 |
66 |
Furthermore, the CL-Signature implementation allows the unlinkability of a
|
| 67 |
67 |
certificate issued with this certificate shown to verifiers. In other words,
|
| 68 |
68 |
the certificate signature can not be used as a factor of linkability between
|
| 69 |
|
to transactions involving a same certificate. (But many other factors may be
|
|
69 |
the transactions involving a same certificate. (But many other factors may be
|
| 70 |
70 |
used (time correlation, attribute contents, etc.), unlinkability is a huge
|
| 71 |
71 |
paradigm.)
|
| 72 |
72 |
|
| 73 |
73 |
The unlinkability may be expected when a user shows multiple times a same
|
| 74 |
74 |
certificate or between the issuing and showing transactions of this
|
| 75 |
75 |
certificate. The unlinkability of the user transactions is a strong property
|
| 76 |
|
of anonymity and ion some cases a privacy-preserving principle.
|
|
76 |
of anonymity and in some cases a privacy-preserving principle.
|
| 77 |
77 |
|
| 78 |
78 |
For instance, Cryptic can be used to implement e-cash and e-voting
|
| 79 |
79 |
architectures.
|
| 80 |
|
-
|