-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
314 lines (271 loc) · 10.9 KB
/
index.html
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
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
<!DOCTYPE html>
<html>
<head>
<title>Redaction Signature Suite 2016</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline,
-->
<script src='//www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
<script type="text/javascript" class="remove">
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "CG-DRAFT",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "lds-redaction2016",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "WD",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://w3c-ccg.github.io/lds-redaction2016/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
//extraCSS: ["spec.css", "prettify.css"],
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Manu Sporny", url: "http://digitalbazaar.com/",
company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" }
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
authors: [
{ name: "Dave Longley", url: "http://digitalbazaar.com/",
company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
{ name: "Manu Sporny", url: "http://digitalbazaar.com/",
company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" }
],
// extend the bibliography entries
//localBiblio: webpayments.localBiblio,
// name of the WG
wg: "W3C Digital Verification Community Group",
// URI of the public WG page
wgURI: "http://www.w3.org/community/digital-verification/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-digital-verification",
otherLinks: [{
key: "Source control",
data: [{
value: "https://github.com/w3c-ccg/lds-redaction2016/",
href: "https://github.com/w3c-ccg/lds-redaction2016/"
}]
}, {
key: "Issue Tracker",
data: [{
value: "https://github.com/w3c-ccg/lds-redaction2016/issues/",
href: "https://github.com/w3c-ccg/lds-redaction2016/issues/"
}]
}],
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "",
maxTocLevel: 4,
/*preProcess: [ webpayments.preProcess ],
alternateFormats: [ {uri: "diff-20111214.html", label: "diff to previous version"} ],
*/
localBiblio: {
"RDF-DATASET-NORMALIZATION": {
title: "RDF Dataset Normalization 1.0",
href: "http://json-ld.github.io/normalization/spec/",
authors: ["David Longley", "Manu Sporny"],
status: "CGDRAFT",
publisher: "JSON-LD Community Group"
},
"SECURITY-VOCABULARY": {
title: "Security Linked Data Vocabulary",
href: "https://web-payments.org/vocabs/security",
authors: ["Manu Sporny","David Longley"],
status: "CGDRAFT",
publisher: "Web Payments Community Group"
},
"LD-SIGNATURES": {
title: "Linked Data Signatures 1.0",
href: "https://web-payments.org/specs/source/ld-signatures/",
authors: ["David Longley", "Manu Sporny"],
status: "CGDRAFT",
publisher: "Web Payments Community Group"
}
}
};
</script>
</head>
<body>
<section id='abstract'>
<p>
This specification describes the Redaction Signature Suite created in 2016 for the
Linked Data Signatures specification. It enables a sender to redact
information in a message without invalidating the digital signature.
</p>
</section>
<section id='sotd'>
<p>
This is an experimental specification and is undergoing regular revisions. It
is not fit for production deployment.
</p>
</section>
<section>
<h2>Introduction</h2>
<p>
This specification describes the Redaction Signature Suite created in 2016
for the Linked Data Signatures [[LD-SIGNATURES]] specification. It uses the
Merkleized form of the RDF Dataset Normalization Algorithm
[[RDF-DATASET-NORMALIZATION]] to transform the input document into its
canonical form. It uses SHA-256 [[RFC6234]] as the
<a>message digest algorithm</a> and RSASSA-PKCS1-v1_5 [[RFC3447]] as the
<a>signature algorithm</a>.
</p>
</section>
<section>
<h2>Terminology</h2>
<p>
The following terms are used to describe concepts involved in the
generation and verification of the Linked Data Signature 2016
<a>signature suite</a>.
</p>
<dl>
<dt><dfn>signature suite</dfn></dt>
<dd>
A specified set of cryptographic primitives typically consisting of
a canonicalization algorithm, a message digest algorithm, and a signature
algorithm that are bundled together by cryptographers for developers
for the purposes of safety and convenience.
</dd>
<dt><dfn>canonicalization algorithm</dfn></dt>
<dd>
An algorithm that takes an input document that has more than one possible
representation and always transforms it into a canonical form. This process is
sometimes also called normalization.
</dd>
<dt><dfn>message digest algorithm</dfn></dt>
<dd>
An algorithm that takes an input message and produces a cryptographic
output message that is often many orders of magnitude smaller than the
input message. These algorithms are often 1) very fast, 2)
non-reversible, 3) cause the output to change significantly when even one
bit of the input message changes, and 4) make it infeasible to find two
different inputs for the same output.
</dd>
<dt><dfn>signature algorithm</dfn></dt>
<dd>
An algorithm that takes an input message and produces an output value where the
receiver of the message can mathematically verify that the message has not
been modified in transit and came from someone possessing a particular secret.
</dd>
</dl>
</section>
<section>
<h2>The 2016 Redaction Signature Suite</h2>
<p>
The 2016 Redaction <a>signature suite</a> MUST be used in
conjunction with the signing and verification algorithms in the
Linked Data Signatures [[LD-SIGNATURES]] specification. The suite consists of
the following algorithms:
</p>
<table class="simple">
<thead>
<th>Parameter</th>
<th>Value</th>
<th>Specification</th>
</thead>
<tbody>
<tr>
<td>canonicalizationAlgorithm</td>
<td>https://w3id.org/security#MURDNA2015</td>
<td>[[RDF-DATASET-NORMALIZATION]]</td>
</tr>
<tr>
<td>digestAlgorithm</td>
<td>http://example.com/digests#sha256</td>
<td>[[RFC6234]]</td>
</tr>
<tr>
<td>signatureAlgorithm</td>
<td>http://www.w3.org/2000/09/xmldsig#rsa-sha1</td>
<td>[[RFC3447]]</td>
</tr>
</tbody>
</table>
<section>
<h2>Modification to Algorithms</h2>
<p>
No modifications to the Linked Data Signature algorithms are provided other
than the algorithms specified in the previous signature suite section.
</p>
</section>
<section>
<h2>Security Considerations</h2>
<p>
The following section describes security considerations that developers
implementing this specification should be aware of in order to create secure
software.
</p>
<div class="issue">TODO: We need to add a complete list of security
considerations.</div>
</section>
<section class="appendix">
<h2>Examples</h2>
<p>
A simple example of a Redaction 2016 signature:
</p>
<pre class="example highlight">
{
"@context": ["http://schema.org/", "https://w3id.org/security/v1"],
"description": "Hello world!",
"socialSecurityNumber": "ni://redaction-sha256;813f2d3396f038c3226fb70327efacd068284c93a857453fc52441c90b0b797d",
"signature": {
"type": "RedactionSignature2016",
"created": "2016-11-07T05:33:31Z",
"creator": "https://example.com/jdoe/keys/1",
"domain": "example.com",
"signatureValue": "OQeEhRZYzHUm6B7eImIsIRmtEMzULkk1J2efEYT+qzk9v58E3C5iA8eCeQc/7+qRj2TfqXN29DtEGOGaKHMcp4d90AiJvVvMb+8z9PwvWNCDAZKQ9pZp23MtHqV7kym7s6KIaYWO8gMNpnEwSoaNIF61JQkuoEDrnNECHRRsAOY="
}
}
</pre>
<p>
To verify the signature above, a verifier would first use the
RDF Dataset normalization algorithm to normalize the content above.
</p>
<pre class="example highlight">
_:c14n0 <http://schema.org/description> "Hello world!" .
_:c14n0 <http://schema.org/socialSecurityNumber> "ni://redaction-sha256;813f2d3396f038c3226fb70327efacd068284c93a857453fc52441c90b0b797d" .
</pre>
<p>
All redaction-sha256 hashes would be replaced with their hash value:
</p>
<pre class="example highlight">
_:c14n0 <http://schema.org/description> "Hello world!" .
813f2d3396f038c3226fb70327efacd068284c93a857453fc52441c90b0b797d
</pre>
<p>
All remaining lines would be hashed:
</p>
<pre class="example highlight">
d5abfa3bb592cfdc09d130daa9de861768e129647de86cf239dcc1b1b4085597
813f2d3396f038c3226fb70327efacd068284c93a857453fc52441c90b0b797d
</pre>
<p>
All hashes would then be sorted:
</p>
<pre class="example highlight">
813f2d3396f038c3226fb70327efacd068284c93a857453fc52441c90b0b797d
d5abfa3bb592cfdc09d130daa9de861768e129647de86cf239dcc1b1b4085597
</pre>
<p>
The data above would then be hashed again and then a standard
signature verification algorithm, such as RSA, would be employed to
verify that the signature is valid.
</p>
</section>
</body>
</html>