File: rfc3029.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2859 lines) | stat: -rw-r--r-- 107,347 bytes parent folder | download | duplicates (5)
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
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859






Network Working Group                                           C. Adams
Request for Comments: 3029                          Entrust Technologies
Category: Experimental                                      P. Sylvester
                                     EdelWeb SA - Groupe ON-X Consulting
                                                            M. Zolotarev
                                      Baltimore Technologies Pty Limited
                                                           R. Zuccherato
                                                    Entrust Technologies
                                                           February 2001


                Internet X.509 Public Key Infrastructure
           Data Validation and Certification Server Protocols

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes a general Data Validation and Certification
   Server (DVCS) and the protocols to be used when communicating with
   it.  The Data Validation and Certification Server is a Trusted Third
   Party (TTP) that can be used as one component in building reliable
   non-repudiation services.

   Useful Data Validation and Certification Server responsibilities in a
   PKI are to assert the validity of signed documents, public key
   certificates, and the possession or existence of data.

   Assertions created by this protocol are called Data Validation
   Certificates (DVC).

   We give examples of how to use the Data Validation and Certification
   Server to extend the lifetime of a signature beyond key expiry or
   revocation and to query the Data Validation and Certification Server
   regarding the status of a public key certificate.  The document
   includes a complete example of a time stamping transaction.






Adams, et al.                 Experimental                      [Page 1]

RFC 3029                     DVCS Protocols                February 2001


Table of Contents

   1. Introduction .................................................  2
   2. Services provided by DVCS ....................................  4
    2.1 Certification of Possession of Data ........................  4
    2.2 Certification of Claim of Possession of Data ...............  4
    2.3 Validation of Digitally Signed Documents ...................  4
    2.4 Validation of Public Key Certificates ......................  5
   3. Data Certification Server Usage and Scenarii .................  5
   4. Functional Requirements for DVCS .............................  7
   5. Data Certification Server Transactions .......................  7
   6. Identification of the DVCS ...................................  8
   7. Common Data Types ............................................  9
    7.1 Version ....................................................  9
    7.2 DigestInfo ................................................. 10
    7.3. Time Values ............................................... 10
    7.4. PKIStatusInfo ............................................. 11
    7.5. TargetEtcChain ............................................ 11
    7.6. DVCSRequestInformation .................................... 12
    7.7. GeneralName and GeneralNames .............................. 13
   8. Data Validation and Certification Requests ................... 13
   9. DVCS Responses ............................................... 17
    9.1. Data Validation Certificate ............................... 18
    9.2. DVCS Error Notification ................................... 21
   10. Transports .................................................. 22
    10.1 DVCS Protocol via HTTP or HTTPS ........................... 22
    10.2 DVCS Protocol Using Email ................................. 22
   11. Security Considerations ..................................... 23
   12. Patent Information .......................................... 23
   13. References .................................................. 25
   14. Authors' Addresses .......................................... 26
   APPENDIX A - PKCS #9 Attribute .................................. 27
   APPENDIX B - Signed document validation ......................... 27
   APPENDIX C - Verifying the Status of a Public Key Certificate ... 28
   Appendix D - MIME Registration .................................. 30
   Appendix E - ASN.1 Module using 1988 Syntax ..................... 31
   Appendix F - Examples ........................................... 34
   Appendix G - Acknowledgements ................................... 50
   Full Copyright Statement ........................................ 51

1. Introduction

   This document is the result of work that has been proposed and
   discussed within the IETF PKIX working group.  The authors and some
   members of the group felt that promoting the rather new concepts into
   the standards process seemed premature.  The concepts presented have
   been stable for some time and partially implemented.  It was agreed
   that a publication as experimental RFC was an appropriate means to



Adams, et al.                 Experimental                      [Page 2]

RFC 3029                     DVCS Protocols                February 2001


   get a stable reference document to permit other implementations to
   occur.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
   as shown) are to be interpreted as described in [RFC2119].

   A Data Validation and Certification Server (DVCS) is a Trusted Third
   Party (TTP) providing data validation services, asserting correctness
   of digitally signed documents, validity of public key certificates,
   and possession or existence of data.

   As a result of the validation, a DVCS generates a Data Validation
   Certificate (DVC).  The data validation certificate can be used for
   constructing evidence of non-repudiation relating to the validity and
   correctness of an entity's claim to possess data, the validity and
   revocation status of an entity's public key certificate and the
   validity and correctness of a digitally signed document.

   Services provided by a DVCS do not replace the usage of CRLs and OCSP
   for public key certificate revocation checking in large open
   environments, due to concerns about the scalability of the protocol.

   It should be rather used to support non-repudiation or to supplement
   more traditional services concerning paperless document environments.
   The presence of a data validation certificate supports
   non-repudiation by providing evidence that a digitally signed
   document or public key certificate was valid at the time indicated in
   the DVC.

   A DVC validating a public key certificate can for example be used
   even after the public key certificate expires and its revocation
   information is no longer or not easily available.  Determining the
   validity of a DVC is assumed to be a simpler task, for example, if
   the population of DVCS is significantly smaller than the population
   of public key certificate owners.

   An important feature of the protocol is that DVCs can be validated by
   using the same protocol (not necessarily using the same service), and
   the validity of a signed document, in particular a DVC, can also be
   determined by means other than by verifying its signature(s), e.g.,
   by comparing against an archive.

   The production of a data validation certificate in response to a
   signed request for validation of a signed document or public key
   certificate also provides evidence that due diligence was performed
   by the requester in validating a digital signature or public key
   certificate.



Adams, et al.                 Experimental                      [Page 3]

RFC 3029                     DVCS Protocols                February 2001


   This document defines the use of digital signatures to insure the
   authenticity of documents and DVCs, and uses a corresponding
   terminology; the use of other methods to provide evidence for
   authenticity is not excluded, in particular it is possible to replace
   a SignedData security envelope by another one.

2. Services provided by DVCS

   The current specification defines 4 types of validation and
   certification services:

   - Certification of Possession of Data (cpd),
   - Certification of Claim of Possession of Data (ccpd),
   - Validation of Digitally Signed Document (vsd), and
   - Validation of Public Key Certificates (vpkc).

   A DVCS MUST support at least a subset of these services.  A DVCS may
   support a restricted vsd service allowing to validate data validation
   certificates.

   On completion of each service, the DVCS produces a data validation
   certificate - a signed document containing the validation results and
   trustworthy time information.

2.1 Certification of Possession of Data

   The Certification of Possession of Data service provides evidence
   that the requester possessed data at the time indicated and that the
   actual data were presented to the Data Validation Server.

2.2 Certification of Claim of Possession of Data

   The Certification of Claim of Possession of Data service is similar
   to the previous one, except that the requester does not present the
   data itself but a message digest.

2.3 Validation of Digitally Signed Documents

   The Validation of Digitally Signed Document service is used when
   validity of a signed document is to be asserted.

   The DVCS verifies all signatures attached to the signed document
   using all appropriate status information and public key certificates.
   The DVCS verifies the mathematical correctness of all signatures
   attached to the document and also checks whether the signing entities
   can be trusted, for example by validating the full certification path
   from the signing entities to a trusted point (e.g., the DVCS's CA, or
   the root CA in a hierarchy).



Adams, et al.                 Experimental                      [Page 4]

RFC 3029                     DVCS Protocols                February 2001


   The DVCS may be able to rely on relevant CRLs or may need to
   supplement this with access to more current status information from
   the CAs for example by accessing an OCSP service, a trusted directory
   service, or other DVCS services.

   The DVCS will perform verification of all signatures attached to the
   signed document.  A failure of the verification of one of the
   signatures does not necessarily result in the failure of the entire
   validation, and vice versa, a global failure may occur if the
   document has an insufficient number of signatures.

2.4 Validation of Public Key Certificates

   The Validation of Public Key Certificates service is used to verify
   and assert the validity (according to [RFC2459]) of one or more
   public key certificates at the specified time.

   When verifying a public key certificate, the DVCS verifies that the
   certificate included in the request is a valid certificate and
   determines its revocation status at a specified time.  DVS checks the
   full certification path from the certificate's issuer to a trusted
   point.  Again, the DVCS MAY be able to rely on external information
   (CRL, OCSP, DVCS).

3. Data Certification Server Usage and Scenarii.

   It is outside the scope of this document to completely describe
   different operational scenarii or usages for DVCS.

   See Appendix B and C for a set of some basic examples and use cases.

   The Validate Signed Document service can be used to support non-
   repudiation services, to allow use of the signed document beyond
   public key certificate revocation or expiry, or simply to delegate
   signature validation to a trusted central (company wide) service.

   The Validate Public Key Certificate service can be used when timely
   information regarding a certificate's revocation status is required
   (e.g., high value funds transfer or the compromise of a highly
   sensitive key) or when evidence supporting non-repudiation is
   required.

   A data validation certificate may be used to simplify the validation
   of a signature beyond the expiry or subsequent revocation of the
   signing certificate: a Data validation certificate used as an
   authenticated attribute in a signature includes an additional





Adams, et al.                 Experimental                      [Page 5]

RFC 3029                     DVCS Protocols                February 2001


   assertion about the usability of a certificate that was used for
   signing.  In order to validate such a signature it may be sufficient
   to only validate the data validation certificate.

   A DVCS may include additional key exchange certificates in a data
   validation certificate to validate a key exchange certificate in
   order to provide to an application a set of additional authorised
   recipients for which a session key should also be encrypted.  This
   can be used for example to provide central management of a company
   wide recovery scheme.  Note, that the additional certificates may not
   only depend on the requested certificate, but also on the requester's
   identity.

   The Certification of Claim of Possession of Data service is also
   known as time stamping.

   The Certification of Possession of Data service can be used to assert
   legal deposit of documents, or to implement archival services as a
   trusted third party service.

   The Data Validation and Certification Server Protocols can be used in
   different service contexts.  Examples include company-wide
   centralised services (verification of signatures, certification of
   company certificates), services to cooperate in a multi-organization
   community, or general third party services for time stamping or data
   archival.

   An important application of DVCS is an enterprise environment where
   all security decisions are based on company wide rules.  A company
   wide DVCS service can be used to delegate all technical decisions
   (e.g., path validation, trust configuration) to a centrally managed
   service.

   In all cases, the trust that PKI entities have in the Data Validation
   and Certification Server is transferred to the contents of the Data
   Validation Certificate  (just as trust in a CA is transferred to the
   public key certificates that it issues).

   A DVCS service may be combined with or use archiving and logging
   systems, in order to serve as a strong building block in non-
   repudiation services.  In this sense it can be regarded as an
   Evidence Recording Authority [ISO-NR].









Adams, et al.                 Experimental                      [Page 6]

RFC 3029                     DVCS Protocols                February 2001


4. Functional Requirements for DVCS

   The DVCS MUST

   1. provide a signed response in the form of a data validation
      certificate to the requester, as defined by policy, or an error
      response.  The DVCS service definition and the policy define how
      much information that has been used by the DVCS to generate the
      response will be included in a data validation certificate, e.g.,
      public key certificates, CRLs, and responses from other OCSP
      servers, DVCS, or others.

   2. indicate in the data validation certificate whether or not the
      signed document, the public key certificate(s), or the data were
      validated, and, if not, the reason why the verification failed.

   3. include a strictly monotonically increasing serial number in each
      data validation certificate.

   4. include a time of day value or a time stamp token into each data
      validation certificate.

   5. sign each data certification token using a key that has been
      certified with a dvcs signing extended key purpose, and include a
      reference to this certificate as a signed attribute in the
      signature.

   6. check the validity of its own signing key and certificate before
      delivering data validation certificates and MUST not deliver data
      validation certificate in case of failure.

   A DVCS SHOULD include within each data validation certificate a
   policy identifier to determine the trust and validation policy used
   for DVC's signature.

5. Data Certification Server Transactions

   A DVCS transaction begins with a client preparing a Data Validation
   and Certification Request.  The request always contains data for
   which validity, correctness or possession is to be certified.

   The request MAY be encapsulated using a security envelope to provide
   for authentication of both requester and server.  Requester
   authentication can be achieved by several of the formats described in
   CMS, in particular, signedData.






Adams, et al.                 Experimental                      [Page 7]

RFC 3029                     DVCS Protocols                February 2001


   The DVCS client chooses an appropriate transport mechanism to convey
   the requests to a DVCS.  It may also be necessary to choose a
   transport mechanism providing confidentiality and, in particular,
   allowing authentication of the DVCS by the requestor, e.g., TLS or
   CMS or S/MIME encryption.

   If the request is valid, the DVCS performs all necessary
   verifications steps, and generates a Data Validation Certificate
   (DVC), and sends a response message containing the DVC back to the
   requestor.

   The Data Validation Certificate is formed as a signed document (CMS
   SignedData).

   As with the request, it may be necessary to choose a transport
   mechanism that provides for confidentiality to carry the DVC.  DVCs
   are not necessarily transported the same way as requests, e.g., they
   can be returned using e-mail after an online request received via
   HTTPS.

   If the request was invalid, the DVCS generates a response message
   containing an appropriate error notification.

   Upon receiving the response, the requesting entity SHOULD verify its
   validity, i.e., whether it contains an acceptable time, the correct
   name for the DVCS, the correct request information and message
   imprint, a valid signature, and satisfactory status, service and
   policy fields.

   When verifying the validity of a DVC, it is up to the requestor's
   application to check whether a DVCS's signing certificate is valid.
   Depending on the usage environment, different methods, online or out
   of band, e.g., CRLs, DVCS, or OCSP, may have to be used.

   After all checks have passed, the data validation certificate can be
   used to authenticate the correctness or possession of the
   corresponding data.

   A DVCS may return more than one DVC corresponding to one request.  In
   this case, all but one request have a global status of 'WAITING'.

6. Identification of the DVCS

   In order to be able to import elements from dvcs the following object
   identifier is used as a ASN.1 module identifier.

   id-mod-dvcs OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
     dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 15}



Adams, et al.                 Experimental                      [Page 8]

RFC 3029                     DVCS Protocols                February 2001


   The DVCS that use SignedData to provide authentication for DVCs MUST
   sign all data certification messages with a key whose corresponding
   certificate MUST contain the extended key usage field extension as
   defined in [RFC2459] Section 4.2.1.14 with KeyPurposeID having value
   id-kp-dvcs.  This extension MUST be marked as critical.

   The Data Validation Certificate MUST contain an ESSCertID
   authenticated attribute for the certificate used by the DVCS for
   signing.

   id-kp-dvcs  OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) 10}

   Consistent KeyUsage bits:

   digitalSignature, nonRepudiation, keyCertSign, cRLSign

   A DVCS's certificate MAY contain an Authority Information Access
   extension [RFC2459] in order to convey the method of contacting the
   DVCS.  The accessMethod field in this extension MUST contain the OID
   id-ad-dvcs:

   id-ad-dvcs  OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) pkix(7) ad(48) 4}

   The value of the 'accessLocation' field defines the transport (e.g.,
   an URI) used to access the DVCS.

7. Common Data Types

   There are several common data types that occur in the request and the
   response data structures.  These data types are either defined by
   this document or imported from other sources.  This chapter defines
   and describes these types and lists their usages.

7.1 Version:

   The request and the response include an optional integer field
   specifying the version of the data structure.  For both fields the
   value is 1, or the field is not present at all in this version of the
   protocol.










Adams, et al.                 Experimental                      [Page 9]

RFC 3029                     DVCS Protocols                February 2001


7.2 DigestInfo:

   This element is defined in [RFC2315].  Since the status of that
   document is informational, the definition is repeated here:

   DigestInfo ::= SEQUENCE {
       digestAlgorithm   DigestAlgorithmIdentifier,
       digest            Digest }

   Digest ::= OCTET STRING

   The fields of type DigestInfo have the following meanings:

   - The field 'digestAlgorithm' identifies the message-digest algorithm
     (and any associated parameters) under which data are digested.

   - The field 'digest' is the result of the message-digesting process.

   A DigestInfo is used in two places:

   - as a data portion for the ccpd service, and

   - in all a data validation certificates to hold a digest of the data
     portion of the corresponding request or a copy of the data field
     for a ccpd service.

7.3. Time Values

   Indicators of time can be present in requests and responses.  In the
   most simple form, the time is represented as GeneralizedTime where
   fractions of seconds are allowed.

   An alternate form is a timeStampToken from a TSA, or as a DVC (or
   some other token) from another third party service.

   It is a matter of policy whether a DVCS tries to interpret or
   validate a Time Value in a request.

   DVCSTime ::= CHOICE  {
        genTime                      GeneralizedTime,
        timeStampToken               ContentInfo }

   Future versions of the protocol MAY include additional time formats.

   Time values generated by the DVCS are increasing but not necessarily
   unique, an order among DVCs is defined by serial numbers.





Adams, et al.                 Experimental                     [Page 10]

RFC 3029                     DVCS Protocols                February 2001


7.4. PKIStatusInfo

   This structure is defined in [RFC2510].  It is used as component of
   the 'chain' field of a TargetEtcChain structure, and as a global
   status indicator in the DVCSResponse structure.  Every occurrence of
   PKIStatusInfo is generated by the responding DVCS to reflect the
   result of some local verification.

7.5. TargetEtcChain

   A TargetEtcChain structure contains certificates and other indicators
   to describe either (in a request for a cpkc service) information to
   be validated, or the result of the verifications.  The structure may
   also contain information about policies and policy mappings.

   The details about how to fill in and to interpret the structure are
   defined later for each service.

   The 'pathProcInput' field contains information about policies and
   policy mapping to be used or used during a validation.

   In a response, the 'pkistatus' and `certstatus' choices can only
   occur in the 'chain' sequence.  If present, they contain the result
   of a local verification of the immediately preceding element, or of
   the target value, if it is the first element in the 'chain' sequence.
   If no 'pkistatus' or 'certstatus' is present, the DVCS considers all
   elements in the 'chain' as trustworthy.  Note, that there may be a
   valid OCSP response or DVC indicating an invalid certificate.

   TargetEtcChain ::= SEQUENCE {
        target                       CertEtcToken,
        chain                        SEQUENCE SIZE (1..MAX) OF
                                        CertEtcToken OPTIONAL,
        pathProcInput                [0] PathProcInput OPTIONAL }

   PathProcInput ::= SEQUENCE {
        acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
                                        PolicyInformation,
        inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
        explicitPolicyReqd           BOOLEAN DEFAULT FALSE }

   CertEtcToken ::= CHOICE {

        certificate                  [0] IMPLICIT Certificate ,
        esscertid                    [1] ESSCertId ,
        pkistatus                    [2] IMPLICIT PKIStatusInfo ,
        assertion                    [3] ContentInfo ,
        crl                          [4] IMPLICIT CertificateList,



Adams, et al.                 Experimental                     [Page 11]

RFC 3029                     DVCS Protocols                February 2001


        ocspcertstatus               [5] IMPLICIT CertStatus,
        oscpcertid                   [6] IMPLICIT CertId ,
        oscpresponse                 [7] IMPLICIT OCSPResponse,
        capabilities                 [8] SMIMECapabilities,
        extension                    Extension }

   Certificate, PolicyInformation and CertificateList are defined in
   [RFC2459].  ESSCertId is defined in [RFC2634].  CertId, OCSPResponse
   and CertStatus are defined in [RFC2560].  PKIStatusField is defined
   in [RFC2510].

   The choice 'assertion' can contain a data validation certificate, or
   a timeStamp, or other assertions.

   The choices 'assertion', 'ocspresponse' and 'crl' are provided by
   services external to the responding DVCS.  The choices 'certStatus'
   and 'pkistatus' reflect decisions made directly by the responding
   DVCS.

   As a replacement for certificates, certification identifiers
   (ESSCertId, CertId)  MAY be used in requests and responses, if this
   is sufficient to perform the service, e.g., when the corresponding
   certificates are provided elsewhere in a request or response (as part
   of the SignedData type).

   Certificate or certification identifiers of certification authorities
   MAY occur in any order and MAY represent several certification
   chains.

   The choice 'capabilities' can be used to indicate SMIMECapabilities.
   It applies to the certificate identified by the preceding element in
   the sequence.

7.6. DVCSRequestInformation

   A DVCSRequestInformation data structure contains general information
   about the Data Validation and Certification Request.  This structure
   occurs in a request, and is also included in a corresponding Data
   Validation Certificate.

   DVCSRequestInformation ::= SEQUENCE  {

           version                      INTEGER DEFAULT 1 ,
           service                      ServiceType,
           nonce                        INTEGER OPTIONAL,
           requestTime                  DVCSTime OPTIONAL,
           requester                    [0] GeneralNames OPTIONAL,
           requestPolicy                [1] PolicyInformation OPTIONAL,



Adams, et al.                 Experimental                     [Page 12]

RFC 3029                     DVCS Protocols                February 2001


           dvcs                         [2] GeneralNames OPTIONAL,
           dataLocations                [3] GeneralNames OPTIONAL,
           extensions                   [4] IMPLICIT Extensions OPTIONAL
   }

   The ServiceType type enumerates the DVCS service type of a request.
   See chapter 2 for the description of the services.

   ServiceType ::= ENUMERATED { cpd(1), vsd(2), cpkc(3), ccpd(4) }

7.7. GeneralName and GeneralNames

   There are several occurrences of SEQUENCES of GeneralName and
   GeneralNames.  These structures are imported from [RFC2459].

8. Data Validation and Certification Requests

   A Data Validation and Certification request is a ContentInfo defined
   in [RFC2630].

   It may consist of a [RFC2630] content with a contenttype id-ct-
   DVCSRequestData signalling a DVCSRequestData,

   id-ct-DVCSRequestData OBJECT IDENTIFIER ::= {iso(1) member-body(2)
     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 7}

   These data are optionally encapsulated by contenttypes that provide
   for authentication and/or confidentiality.

   This document describes the usage of a SignedData construct of
   [RFC2630] where the contenttype indicated in the eContentType of the
   encapContentInfo is id-ct-DVCSRequestData and the eContent of the
   encapContentInfo, carried as an octet string, contains a
   DVCSRequestData structure.

   When using a SignedData structure, a Data Validation and
   Certification Request MAY contain several SignerInfo structures, and
   countersignature attributes depending on operational environments.
   When an end user client creates the request, there is one or zero
   SignerInfo.  A relaying DVCS MAY add an additional signature or a
   countersignature attribute, or MAY use another encapsulation from
   [RFC2630] that provides for authentication and/or confidentiality.

   The content of a request consists of a description of the desired
   service and additional parameters, the data to be validated, and an
   optional identifier of the request.





Adams, et al.                 Experimental                     [Page 13]

RFC 3029                     DVCS Protocols                February 2001


   DVCSRequest ::= SEQUENCE  {
       requestInformation         DVCSRequestInformation,
       data                       Data,
       transactionIdentifier      GeneralName OPTIONAL
   }

   The 'DVCSRequest.requestInformation' element contains general
   information about the request.  It is filled in by the requester as
   follows:

   - The 'version' field is set to 1 or the field is absent in this
     version of the protocol.

     The field 'service' contains the requested service.

   - The 'nonce' field MAY be used to provide additional protection
     against replay or content guessing attacks.

   - The 'requestTime' field MAY be used to indicate the time for which
     the requested service should be performed.  For a vsd and cpkc
     service, it specifies the time for which the validity of a signed
     document or certicates is to be asserted.  For the other service,
     the field is ignored by the DVCS.  If the field is absent, the
     current time is assumed.

   - The value of the 'requester' field indicates the requesting entity.

     The interpretation and usage of this field MUST be defined by the
     DVCS policy.

     Some usage examples are:

     If the field is present, and the request is signed, a DVCS MAY
     require that the field MUST match the identity (subjectName or
     subjectAltName extension) of the corresponding signature
     certificate.

     A request MAY be signed by a DVCS when relaying it to another DVCS.

     When acting as a relay, a DVCS MAY add its own identity in the
     request relayed to another service provider, and it MAY remove the
     initial value.

   - The 'requestPolicy' field SHOULD indicate the policy under which
     the validation is requested.  This field MUST be checked by the
     DVCS to verify agreement with its own policy.  The absence of this
     field indicates that any policy is acceptable.




Adams, et al.                 Experimental                     [Page 14]

RFC 3029                     DVCS Protocols                February 2001


   - The 'dvcs' field MAY be used to indicate a list of DVCS which can
     be contacted to provide (additional) information or to perform
     additional operations necessary to produce the response.

     It is up to the DVCS policy whether to honor this field or not, and
     to define which choice of a general name is acceptable (e.g., an
     URL or a DN).

   - The 'dataLocations' field MAY be used to indicate where a copy of
     the 'data' field of the request or supplementary information can be
     obtained.  The DVCS does not use this field for its own operation,
     the exact interpretation of this field is defined by applications.

   - The 'requestTime' field MAY be used to indicate the time for which
     the requested service should be performed.  For a vsd and cpkc
     service, it specifies the time for which the validity of a signed
     document or certicates is to be asserted.  For the other service,
     the field is ignored by the DVCS.  If the field is absent, the
     current time is assumed.  The DVCS service may have a time limit or
     a delta time limit regarding current time which are specified in
     the local policy of the DVCS service.

   - The 'extensions' field MAY be used to include additional
     information.  Extensions may be marked critical or not in order to
     indicate whether the DVCS is supposed to understand them.  This
     document does not define extensions.

   The DVCSRequest.data contains service-specific content, defined by
   each particular service provided by the DVCS.

   Depending on the requested service type, the field may contain a
   signed document, a list of certificates, a message digest or
   arbitrary data.

   The following type is used:

   Data ::= CHOICE {
         message           OCTET STRING ,
         messageImprint    DigestInfo,
         certs             SEQUENCE SIZE (1..MAX) OF
                               TargetEtcChain
   }

   The requester fills the 'data' element as follows:

   - For a vsd service request, the requestor encapsulates a CMS
     SignedData object in the value octets of the 'message' choice.




Adams, et al.                 Experimental                     [Page 15]

RFC 3029                     DVCS Protocols                February 2001


     It is up to the requester to decide whether and how to provide any
     certificate that may be needed to verify the signature(s) in the
     signedData object.  A requester MAY add certificates to the
     encapsulated signedData object or in the certificate list of the
     request.

   - For a cpkc service request the 'certs' choice is used.

     Each certificate to be verified MUST be included in a separate
     instance of TargetEtcChain.  The 'TargetEtcChain.chain' field, if
     present, indicates one or more chains of trust that can be used to
     validate the certificate.  The DVCS MAY choose to select a subset
     of certificates as certification path, or to ignore this field.
     The 'TargetEtcChain.pathProcInput' field, if present, indicates the
     acceptable policy set and initial settings for explicit-policy-
     indicator and inhibit-policy-mapping indicators to be used in X.509
     public key certificate path validation (see [RFC2459]).

     Only the Certificate, ESSCertId, CertId or Extension choices of the
     TargetEtcChain can be used in the request.

     The requester is responsible for providing sufficient information
     to the DVCS to identify the corresponding certificates.

   - For a ccpd service the 'messageImprint' choice is used.

     The hash algorithm indicated in the hashAlgorithm field SHOULD be a
     "strong" hash algorithm (that is, it SHOULD be one-way and
     collision resistant).  It is up to the Data Certification Server to
     decide whether or not the given hash algorithm is sufficiently
     "strong" (based on the current state of knowledge in cryptanalysis
     and the current state of the art in computational resources, for
     example).

   - For a cpd service the 'message' choice is used.

     The field contains requester-specific data with any type of
     content.  The DVCS does not inspect, modify, or take any particular
     action based on the particular content of the 'message' field.

   The field 'DVCSRequest.transactionIdentifier' MAY be used in order to
   associate DVCS responses containing error messages, to requests.  For
   example, in a mail based environment, the parameter could be a copy
   of a messageid.  Note, that the transactionIdentifier is not
   necessary for associating a request with a valid data validation
   certificate.





Adams, et al.                 Experimental                     [Page 16]

RFC 3029                     DVCS Protocols                February 2001


9. DVCS Responses

   This chapters describes the data structures that are created by a
   DVCS to indicate the results of validation and certification
   requests.

   A DVCS Response structure is generated by the DVCS as a result of
   processing of the data validation and certification request.

   A Data Validation response contains an [RFC2630] ContentInfo with a
   type of id-ct-DVCSResponseData signalling a DVCSResponse structure.

   id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 8 }

   The data MAY be encapsulated by constructs of [RFC2630] in order to
   provide authentication of the DVCS, and or integrity and
   confidentiality of the request.  This document specifies the usage of
   a SignedData construct of [RFC2630].

   The contenttype indicated in the eContentType of the encapContentInfo
   is of type id-ct-DVCSResponseData, signalling a DVCSResponse as
   eContent of the encapContentInfo (carried as an octet string).  The
   DVCS SHOULD use a key for which a corresponding certificate indicates
   in an extendedKeyUsage the purpose of DVCS signing.

   In a critical situation when a DVCS cannot produce a valid signature
   (if the DVCS's signing key is known to be compromised, for example),
   the DVCSResponse, containing the error notification, MUST be
   generated as a signedData with no signerInfo attached.  Receiving
   unsigned DVCSResponse MUST be treated by the clients as a critical
   and fatal error, and the content of the message should not be
   implicitly trusted.

   A valid response can contain one of the following:

   1. A Data Validation Certificate (DVC), delivering the results of
      data validation operations, performed by the DVCS.

   2. An error notification.  This may happen when a request fails due
      to a parsing error, requester authentication failure, or anything
      else that prevented the DVCS from executing the request.









Adams, et al.                 Experimental                     [Page 17]

RFC 3029                     DVCS Protocols                February 2001


   The following type is used:

   DVCSResponse ::= CHOICE {
       dvCertInfo         DVCSCertInfo ,
       dvErrorNote        [0] DVCSErrorNotice }

9.1. Data Validation Certificate

   A Data Validation Certificate is a signedData object containing a
   DVCSResponse with a 'dvCertInfo' choice.

   DVCSCertInfo::= SEQUENCE  {
            version             Integer DEFAULT 1 ,
            dvReqInfo           DVCSRequestInformation,
            messageImprint      DigestInfo,
            serialNumber        Integer,
            responseTime        DVCSTime,
            dvStatus            [0] PKIStatusInfo OPTIONAL,
            policy              [1] PolicyInformation OPTIONAL,
            reqSignature        [2] SignerInfos  OPTIONAL,
            certs               [3] SEQUENCE SIZE (1..MAX) OF
                                    TargetEtcChain OPTIONAL,
            extensions          Extensions OPTIONAL }

   The DVCSCertInfo structure is returned as a result of successful
   execution of data validation service.  It contains the results of the
   data validation, a reference to the original request, and other
   parameters.  Please note that 'successful execution' does not
   necessarily mean that the validation itself was successful - a
   DVCSCertInfo may contain both the 'valid' and 'invalid' results.

   The DVCS creates a DVCSCertInfo as follows:

   - The 'version' field is never present in this version of the
     protocol.

     The 'dvReqInfo' is essentially a copy of the 'requestInformation'
     field of the corresponding request.  The DVCS MAY modify the fields
     'dvcs', 'requester', 'dataLocations', and 'nonce' of the ReqInfo
     structure, e.g., if the request was processed by a chain of DVCS,
     if the request needs to indicate DVCS, or to indicate where to find
     a copy of the data from a 'vpd' request.  The only modification
     allowed to a 'nonce' is the inclusion of a new field if it was not
     present, or to concatenate other data to the end (right) of an
     existing value.






Adams, et al.                 Experimental                     [Page 18]

RFC 3029                     DVCS Protocols                February 2001


   - The 'DVCSCertInfo.messageImprint' field is computed from the 'data'
     field of the corresponding request as follows:

     For the 'certs' choice (the 'vpkc' service), the digest is computed
     over the DER encoded data value.  For a 'message' choice (the 'vsd'
     and the 'vpd' services) the digest is computed over the value
     octets (not including tag and length octets) of the OCTET STRING.
     It is up to the DVCS to choose an appropriate digest algorithm.

     For a 'messageImprint' choice (the 'vcpd' service), the
     'messageImprint' of the DVCSRequest is copied as is.

   - The 'DVCSCertInfo.serialNumber' field contains a unique identifier
     of the request.

   - The field 'responseTime' indicates a time value associated with the
     response.  The value MAY be a locally generated one, or a signed
     TimeStampToken (TST) or DVC obtained from an external service.
     Before using a value obtained from an external service, the DVCS
     must validate it according the rules of the external service.

   - The field 'DVCSCertInfo.dvStatus' reflects a collective result of
     the validation.

     If the field is missing, it is an equivalent of the SUCCESS
     status.

     For a vkpc, if the status field is present and set to SUCCESS, it
     indicates that all certificates were successfully validated.  If it
     is present and set to FAILED, it indicates that all or some of the
     certificates failed validation, and the specific status of the
     'certs' should be investigated, at least one of the elements of the
     'certs' TargetEtcChain structures MUST have a failure status.

     If the field 'dvStatus' does not indicate success ('granted' or
     'granted with mods') the element 'failInfo' MAY indicate the reason
     for the failure.  Note that the field 'certs' MAY contain
     additional information about verification failures.

     A failure of the verification of one of the signatures does not
     necessarily result in failing to validate a signed document.  For
     example, as long as a sufficient number of signature was
     successfully verified, a DVC with status 'grantedWithMods' may be
     produced.  A DVC with status 'granted' MUST only be produced if all
     signatures verified successfully.






Adams, et al.                 Experimental                     [Page 19]

RFC 3029                     DVCS Protocols                February 2001


     The field MUST be present, and the status must be set to WAITING,
     if no final response can be immediately available.  It is assumed
     that the DVCS provides an additional final status some time later.
     The details of the necessary procedures are part of the DVCS
     policy.

     In case of failure, the requester can further investigate the cause
     of the failure, by looking into the TargetEtcChain fields.
     'CertEtctoken.pkistatus' fields will indicate which item(s) has
     failed or succeeded the validation and for what reason.

   - The 'DVCSCertInfo.policy' field indicates the policy under which
     the DVCS operates.

   - If present, 'DVCSCertInfo.reqSignature' MUST be the same value as
     the signerInfos field of the corresponding request.  It is a policy
     decision whether to include this field.

   - The 'DVCSCertInfo.certs' field contains the results of the
     verifications made by the DVCS.  For the cpkc service, each element
     contains a copy of a corresponding field of the request with the
     selected subset in the targetAndChain subfield and the results of
     the verifications, and additional certificates or certificate
     references, e.g., from certification authorities or as described in
     appendix C.3.  For a vsd service, each element contains the result
     of the validation of one signature of the signed document to be
     validated.

     In case of a global status of WAITING, the DVCS MAY choose to
     return an individual status of waiting in some of the 'certs'
     field, or not to return such a TargetEtcChain at all.

     The 'acceptablePolicySet' sequence indicates the policies and
     mappings that were processed during X.509 public key certificate
     path validation.  PolicyMappingsSyntax is defined in [RFC2459].

   - The 'extensions' field MAY be used to return additional information
     to the client.  Extensions MAY be marked critical or not in order
     to indicate whether the client MUST understand them.  This document
     does not define extensions.











Adams, et al.                 Experimental                     [Page 20]

RFC 3029                     DVCS Protocols                February 2001


9.2. DVCS Error Notification

   A DVCS Error Notification is a CMS signedData object containing a
   DVCSResponse with a 'dvErrorNote' choice.

   DVCSErrorNotice ::= SEQUENCE {
       transactionStatus           PKIStatusInfo ,
       transactionIdentifier       GeneralName OPTIONAL }

   The PKIStatusInfo is defined in [RFC2511].  For the purposes of
   communicating the DVCSErrorNotice, the following subset of
   PKIFailureInfo values is used:

   PKIFailureInfo ::= BITSTRING  {

        badRequest       (2),
        -- transaction not permitted or supported
        badTime          (3),
        -- messageTime was not sufficiently close to the system time,
        -- as defined by local policy
        badDataFormat    (5),
        -- the data submitted has the wrong format
        wrongAuthority   (6),
        -- the DVCS indicated in the request is different from the
        -- one creating the response token
        incorrectData    (7)
        --the requester's data (i.e., signature) is incorrect )

   In the DVCSErrorNotice, the PKIStatus field of the PKIStatusInfo must
   be set to REJECTED.

   The 'statusString' field of PKIStatusInfo can be used to accommodate
   extra text, such as a reason for the failure, for example "I have
   gone out of service".  The DVCS initializes the
   'DVCSErrorNotice.transactionIdentifier' with a copy of the
   'DVCSRequest.transactionIdentifier' field of the corresponding
   request.

   In certain circumstances, a DVCS may not be able to produce a valid
   response to a request (for example, if it is unable to compute
   signatures for a period of time).  In these situations the DVCS MAY
   create a response with an DVCSErrorNotice but no signature.

   DVCS clients SHOULD NOT trust unsigned responses.  A DVCS client MAY
   trust unsigned responses, if the communication channel provides for
   server authentication (e.g., by services defined by TLS [RFC2246]).





Adams, et al.                 Experimental                     [Page 21]

RFC 3029                     DVCS Protocols                February 2001


10.  Transports

   There is no mandatory transport mechanism in this document.  All
   mechanisms are optional.  Two examples of transport protocols are
   given which allow online exchange of request and a response, and
   asynchronous communication between a client and a DVCS.

   A DVCS MAY use a combination of protocols, for example in order to
   return additional DVCs.

10.1 DVCS Protocol via HTTP or HTTPS

   This subsection specifies a means for conveying ASN.1-encoded
   messages for the DVCS protocol exchanges via the HyperText Transfer
   Protocol.

   The DER encoded DVCS requests and responses are encapsulated using a
   simple MIME object with Content-Type application/dvcs (and with the
   default binary encoding).

   This MIME object can be sent and received using common HTTP or HTTPS
   processing engines over WWW links and provides a simple client-server
   transport for DVCS messages.

10.2 DVCS Protocol Using Email

   This section specifies a means for conveying ASN.1-encoded messages
   for the protocol exchanges described in Section 8 via Internet mail.

   The DER encoded DVCS requests and responses are encapsulated using a
   simple MIME object with Content-Type application/dvcs with an
   appropriate Content-Transfer-Encoding.

   This MIME object can be sent and received using MIME processing
   engines and provides a simple Internet mail transport for DVCS
   messages.

   In order to be able to associate a possible error response with a
   request, the requester SHOULD use the field 'transactionIdentifier'.
   The requester SHOULD not make any assumption about the usage of
   message header fields by the responding service, in particular the
   usage of fields like Subject, Message-ID or References.









Adams, et al.                 Experimental                     [Page 22]

RFC 3029                     DVCS Protocols                February 2001


11.  Security Considerations

   This entire chapter discusses security considerations.

   When designing a data validation and certification service, the
   following considerations have been identified that have an impact
   upon the validity or "trust" in the data validation certificate.

   It is imperative that keys used to sign DVCs are guarded with proper
   security and controls in order to minimize the possibility of
   compromise.  Nevertheless, in case the private key does become
   compromised, an audit trail of all the DVC generated by the DVCS
   SHOULD be kept as a means to help discriminate between genuine and
   false DVCs.  A DVCS MAY provide for a vsd service to validate DVCs
   created by this DVCS or another one solely based on the audit trail.

   When confidentiality and server authentication is required, requests
   and responses MAY be protected using appropriate mechanisms (e.g.,
   CMS encapsulation [RFC 2630] or TLS [RFC2246]).

   Server authentication is highly recommended for the vsd and cpd
   service.

   Client identification and authentication MAY use services defined by
   TLS [RFC2246]) instead of, or in addition to, using a CMS format
   providing authentication.

12.  Patent Information

   The following United States Patents related to data validation and
   certification services, listed in chronological order, are known by
   the authors to exist at this time.  This may not be an exhaustive
   list.  Other patents may exist or be issued at any time.
   Implementers of the DVCS protocol and applications using the protocol
   SHOULD perform their own patent search and determine whether or not
   any encumberences exist on their implementation.

# 4,309,569     Method of Providing Digital Signatures
(issued) January 5, 1982
(inventor) Ralph C.  Merkle
(assignee) The Board of Trustees of the Leland Stanford Junior
University

# 5,001,752     Public/Key Date-Time Notary Facility
(issued) March 19, 1991
(inventor) Addison M.  Fischer





Adams, et al.                 Experimental                     [Page 23]

RFC 3029                     DVCS Protocols                February 2001


# 5,022,080     Electronic Notary
(issued) June 4, 1991
(inventors) Robert T.  Durst, Kevin D.  Hunter

# 5,136,643     Public/Key Date-Time Notary Facility
(issued) August 4, 1992
(inventor) Addison M.  Fischer
(Note: This is a continuation of patent # 5,001,752.)

# 5,136,646     Digital Document Time-Stamping with Catenate Certificate
(issued) August 4, 1992
(inventors) Stuart A.  Haber, Wakefield S.  Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,136,647     Method for Secure Time-Stamping of Digital Documents
(issued) August 4, 1992
(inventors) Stuart A.  Haber, Wakefield S.  Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,373,561     Method of Extending the Validity of a Cryptographic
Certificate
(issued) December 13, 1994
(inventors) Stuart A.  Haber, Wakefield S.  Stornetta Jr.
(assignee) Bell Communications Research, Inc.,

# 5,422,95 Personal Date/Time Notary Device
(issued) June 6, 1995
(inventor) Addison M.  Fischer

# 5,781,629     Digital Document Authentication System
(issued) July 14, 1998
(inventor) Stuart A. Haber, Wakefield S. Stornetta Jr.
(assignee) Surety Technologies, Inc.,


















Adams, et al.                 Experimental                     [Page 24]

RFC 3029                     DVCS Protocols                February 2001


13.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2510]  Adams, C. and S. Farrell, "Internet X.509 Public Key
              Infrastructure, Certificate Management Protocols", RFC
              2510, March 1999.

   [RFC2459]  Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure, Certificate and CRL
              Profile", RFC 2459, January 1999.

   [RFC2630]  Housley, R., "Cryptographic Message Syntax", RFC 2630,
              June 1999.

   [ISONR]    ISO/IEC 10181-5:  Security Frameworks in Open Systems.
              Non-Repudiation Framework.

   [RFC2119]  Bradner, S., "Key works for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2511]  Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet
              X.509 Certificate Request Message Format", RFC 2511, March
              1999.

   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0",
              RFC 2246, January 1999.

   [RFC2634]  Hoffman P., "Enhanced Security Services for S/MIME", RFC
              2634, June 1999.

   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol", RFC 2560, June 1999.
















Adams, et al.                 Experimental                     [Page 25]

RFC 3029                     DVCS Protocols                February 2001


14.  Authors' Addresses

   Carlisle Adams
   Entrust Technologies
   1000 Innovation Drive
   Ottawa, Ontario
   K2K 3E7
   CANADA

   EMail: cadams@entrust.com


   Michael Zolotarev
   Baltimore Technologies Pty Limited
   5th Floor, 1 James Place
   North Sydney, NSW 2060
   AUSTRALIA

   EMail: mzolotarev@baltimore.com


   Peter Sylvester
   EdelWeb SA - Groupe ON-X Consulting
   15, Quai de Dion Bouton
   F-92816 Puteaux Cedex
   FRANCE

   EMail: peter.sylvester@edelweb.fr


   Robert Zuccherato
   Entrust Technologies
   1000 Innovation Drive
   Ottawa, Ontario
   K2K 3E7
   CANADA

   EMail: robert.zuccherato@entrust.com













Adams, et al.                 Experimental                     [Page 26]

RFC 3029                     DVCS Protocols                February 2001


APPENDIX A - PKCS #9 Attribute

   We define a PKCS #9 [PKCS9] attribute type.  The attribute type has
   ASN.1 type SignedData and contains a data validation certificate.

   The object identifier id-aa-dvcs-dvc identifies the data validation
   certificate attribute type.

   id-aa-dvcs-dvc OBJECT IDENTIFIER ::= {iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 29}

   The attribute may be used as an authenticated or unauthenticated
   attribute in CMS SignedData documents.

APPENDIX B - Signed document validation.

   We present some examples of a possible use of DVCS in the context of
   validation of signed documents.

B.1 Signed document validation

   The example covers the case where a DVCS is used by a signer to
   obtain a proof that a document's structure, including one or more
   attached signatures, is/was correct, after the document was signed.

   The DVC can be produced either by a DVCS that is trusted by the
   signer, or by a DVCS that is trusted by an intended verifier of the
   document.

   The signer uses the obtained DVC as an evidence that its intentions
   were good and it produced a signed document using the
   environment(keys, algorithms, etc) that was known to be OK.

   It produces a stand-alone document that can be used to extend the
   life of a signature.  This example assumes that we have total trust
   in the Data Validation and Certification Server.

   Signature algorithms and keys have a finite lifetime.  Therefore,
   signatures have a finite lifetime.  The Data Certification Server can
   be used to extend the lifetime of a signature.

   In order to extend the lifetime of a signature in this way, the
   following technique can be used:

   1) The signature needs to be certified:

      The signed message is presented to the Data Validation and
      Certification Server in a 'vsd' service request.



Adams, et al.                 Experimental                     [Page 27]

RFC 3029                     DVCS Protocols                February 2001


      The DVCS verifies that the signature and certificates are valid at
      that time by checking expiry dates, status information, or DVCs,
      and returns a DVC.

   2) The DVC SHOULD be verified.

      The signature of the Data Validation and Certification Server in
      data certification token SHALL be verified using the Data
      Certification Server's valid verification key.

   A signer's signing key (and therefore, its signature) is only valid
   until some specified time T1.  The DVCS's signing key (and therefore,
   its signature) is valid until some specified time T2 that is
   (usually) after time T1.  Without certification, the signer's
   signature would only be valid until time T1.  With certification, the
   signer's signature remains valid until time T2, regardless of
   subsequent revocation or expiry at time T1.

   If the signature of the DVCS is valid, the trust we have in the DVCS
   allows us to conclude that the original signature on the data was
   valid at the time included in the DVC.

   The DVCS signing key MUST be of a sufficient length to allow for a
   sufficiently long lifetime.  Even if this is done, the key will have
   a finite lifetime.  Since data validation certificates are just
   another type of signed documents, they can be validated using
   (another) DVCS.

APPENDIX C - Verifying the Status of a Public Key Certificate

   We now present three examples of how to produce a data validation
   certificate that can be used to assert that a public key certificate
   is valid, trusted, and can be used for a particular purpose.

   A client wants to use a given public key certificate either to use it
   to verify a signature on a document or to use it for document
   encryption.

   A DVCS MUST have access to current information regarding public
   certificate status, it can therefore be used to verify the revocation
   status of a certificate at the current time.

   The following technique can be used:

   A) The public key certificate needs to be validated.

      The certificate is presented to the Data Certification Server
      using a 'vpkc' service.



Adams, et al.                 Experimental                     [Page 28]

RFC 3029                     DVCS Protocols                February 2001


      The Data Validation and Certification Server verifies that the
      public key certificate is valid and that it hasn't been revoked
      and then returns a data validation certificate.

   B) The data validation certificate MUST be verified.

      The signature of the Data Certification Server in the data
      certification token SHALL be verified using the Data Validation
      and Certification Server's valid certificate.

   C) The public key certificate is used:

   C.1) A clients's own public key certificate (i.e., the corresponding
        private key) can be used to add a signature to a document.  The
        signing certificate and the data validation certificate can be
        added as signed attributes to the signature.

        A data validation certificate can now be used during the
        validation signatures using the key contained in the public key
        certificate.  This service provided by the DVCS can be thought
        of as a supplement to the usual method of checking revocation
        status.

        In other words, signature validation at a later time does not
        necessarily require access to the revocation status of the
        user's signing certificate, access to a DVCS service and
        validation of the DVC is sufficient to verify a signature.  Note
        that the DVC does not tell when the signature had been created,
        it only indicates when the signing certificate was valid.

   C.2) A public key certificate for key exchange can be used after
        having obtained a data validation certification certificate to
        encrypt data.  The DVC can be stored with the data and/or stored
        by the creator of the encrypted document.

        If an intended recipient of the document claims that the creator
        did not use an appropriate encryption key, the DVC (obtained by
        a recipient's DVCS) can be used as evidence that the recipient's
        DVCS has authorized the usage of the public key.

   C.3) The procedure described in the previous paragraph can be
        enhanced to provide domain encryption in several ways.
        Organizations require that encrypted documents need to be
        recoverable.  One simple way is to always encrypt documents with
        additional recipients that act as 'domain encryption centers' or
        'recovery centers'.  This is not a technically difficult





Adams, et al.                 Experimental                     [Page 29]

RFC 3029                     DVCS Protocols                February 2001


        problem, but may require complicated and difficult interactions
        with the end user, in particular when the document's recipients
        are in several different organizations.

        One possible solution consists of adding additional certificates
        to the dvc that validates the usage of a particular public key
        certificate used for encryption.  In an environment of several
        organizations, one of the possible procedures may be:

        The client asks its local dvcs to validate the public key
        certificate.  The dvcs forwards the request to a dvcs of a
        remote organization.  The remotes organization's dvcs verifies
        the certificate and provides a dvc assertion validating the
        certificate.  It adds additional certificates usable for key
        exchange to the certEtcChain structure indicating additional
        required recipients.  The local dvc creates a dvc containing the
        dvc of the remote dvcs.  It may add additional certificates or
        references to the dvc.  The clients use all validated
        certificates to be usable for key exchange to enhance its list
        of recipients.

        In the local dvcs may as well use local information about the
        remote organization's need for additional recipients.

Appendix D - MIME Registration

   To: ietf-types@iana.org Subject: Registration of MIME media type
   application/timestamp

   MIME media type name: application

   MIME subtype name: dvcs

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary or Base64

   Security considerations: Carries a request for a data validation and
   certification service and the response.  A request may be
   cryptographically signed.  The response will be cryptographically
   signed.

   Interoperability considerations: None

   Published specification:
   RFC 3029 on Data Validation and Certification Server Protocols



Adams, et al.                 Experimental                     [Page 30]

RFC 3029                     DVCS Protocols                February 2001


   Applications which use this media type: Data Validation and
   Certification Servers and Clients

   Additional information:

     Magic number(s): None
     File extension(s): .dvc
     Macintosh File Type Code(s): none

   Person & email address to contact for further information: Peter
   Sylvester <peter.sylvester@edelweb.fr>

   Intended usage: COMMON

   Author/Change controller: Peter Sylvester
   <peter.sylvester@edelweb.fr>

Appendix E - ASN.1 Module using 1988 Syntax

PKIXDVCS {iso(1) identified-organization(3) dod(6) internet(1)
   security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-dvcs(15)}

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- EXPORTS ALL --

IMPORTS
  Extensions, AlgorithmIdentifier
  FROM PKIX1Explicit88 {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
  id-mod(0) id-pkix1-explicit-88(1)}

  GeneralName, PolicyInformation
  FROM PKIX1Implicit88 {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
  id-mod(0) id-pkix1-implicit-88(2)}

  PKIStatusInfo, PKIStatusField FROM PKIXCMP {iso(1)
  identified-organization(3) dod(6) internet(1) security(5)
  mechanisms(5) pkix(7) id-mod(0)
  id-mod-cmp(9)}

  ContentInfo FROM CryptographicMessageSyntax {iso(1)
  member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
  smime(16) modules(0) cms(1)}




Adams, et al.                 Experimental                     [Page 31]

RFC 3029                     DVCS Protocols                February 2001


  ESSCertID FROM ExtendedSecurityServices
  { iso(1) member-body(2) us(840) rsadsi(113549)
  pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }

  CertId, OCSPResponse, CertStatus
  FROM OCSP
  {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-ocsp(14)}

  SMIMECapabilities FROM SecureMimeMessageV3
  { iso(1) member-body(2) us(840) rsadsi(113549)
   pkcs(1) pkcs-9(9) smime(16) modules(0) smime(4) }

  ;

-- Authority Information Access for DVCS

id-ad-dvcs  OBJECT IDENTIFIER ::= {id-pkix id-ad(48) 4}

-- Key Purpose for DVCS

id-kp-dvcs  OBJECT IDENTIFIER ::= {id-pkix id-kp(3) 10}

-- eContentType for a dvcs requests and responses

id-ct-DVCSRequestData  OBJECT IDENTIFIER ::= { id-smime ct(1) 7 }
id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { id-smime ct(1) 8 }

-- Data validation certificate attribute

id-aa-dvcs-dvc OBJECT IDENTIFIER ::= { id-smime aa(2) 29 }

-- using the following bases :

id-pkix     OBJECT IDENTIFIER ::= {iso(1)
               identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5) pkix(7)}

id-smime    OBJECT IDENTIFIER ::= { iso(1) member-body(2)
               us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

Version ::= Integer

DigestInfo ::= SEQUENCE {
    digestAlgorithm   DigestAlgorithmIdentifier,
    digest            Digest
}



Adams, et al.                 Experimental                     [Page 32]

RFC 3029                     DVCS Protocols                February 2001


Digest ::= OCTET STRING

Nonce ::= Integer

DVCSTime ::= CHOICE  {
     genTime                      GeneralizedTime,
     timeStampToken               ContentInfo
}
TargetEtcChain ::= SEQUENCE {
     target                       CertEtcToken,
     chain                        SEQUENCE SIZE (1..MAX) OF
                                     CertEtcToken OPTIONAL,
     pathProcInput                [0] PathProcInput OPTIONAL
}

PathProcInput ::= SEQUENCE {
     acceptablePolicySet          SEQUENCE SIZE (1..MAX) OF
                                     PolicyInformation,
     inhibitPolicyMapping         BOOLEAN DEFAULT FALSE,
     explicitPolicyReqd           BOOLEAN DEFAULT FALSE
}

CertEtcToken ::= CHOICE {
     certificate                  [0] IMPLICIT Certificate ,
     esscertid                    [1] ESSCertId ,
     pkistatus                    [2] IMPLICIT PKIStatusInfo ,
     assertion                    [3] ContentInfo ,
     crl                          [4] IMPLICIT CertificateList,
     ocspcertstatus               [5] IMPLICIT CertStatus,
     oscpcertid                   [6] IMPLICIT CertId ,
     oscpresponse                 [7] IMPLICIT OCSPResponse,
     capabilities                 [8] SMIMECapabilities,
     extension                    Extension
}

DVCSRequestInformation ::= SEQUENCE  {
        version                      INTEGER DEFAULT 1 ,
        service                      ServiceType,
        nonce                        Nonce OPTIONAL,
        requestTime                  DVCSTime OPTIONAL,
        requester                    [0] GeneralNames OPTIONAL,
        requestPolicy                [1] PolicyInformation OPTIONAL,
        dvcs                         [2] GeneralNames OPTIONAL,
        dataLocations                [3] GeneralNames OPTIONAL,
        extensions                   [4] IMPLICIT Extensions OPTIONAL
}

ServiceType ::= ENUMERATED { cpd(1), vsd(2), cpkc(3), ccpd(4) }



Adams, et al.                 Experimental                     [Page 33]

RFC 3029                     DVCS Protocols                February 2001


DVCSRequest ::= SEQUENCE  {
    requestInformation         DVCSRequestInformation,
    data                       Data,
    transactionIdentifier      GeneralName OPTIONAL
}

Data ::= CHOICE {
      message           OCTET STRING ,
      messageImprint    DigestInfo,
      certs             SEQUENCE SIZE (1..MAX) OF
                            TargetEtcChain
}

DVCSResponse ::= CHOICE
{
    dvCertInfo         DVCSCertInfo ,
    dvErrorNote        [0] DVCSErrorNotice
}

DVCSCertInfo::= SEQUENCE  {
         version             Integer DEFAULT 1 ,
         dvReqInfo           DVCSRequestInformation,
         messageImprint      DigestInfo,
         serialNumber        Integer,
         responseTime        DVCSTime,
         dvStatus            [0] PKIStatusInfo OPTIONAL,
         policy              [1] PolicyInformation OPTIONAL,
         reqSignature        [2] SignerInfos  OPTIONAL,
         certs               [3] SEQUENCE SIZE (1..MAX) OF
                                 TargetEtcChain OPTIONAL,
         extensions          Extensions OPTIONAL
}

DVCSErrorNotice ::= SEQUENCE {
    transactionStatus           PKIStatusInfo ,
    transactionIdentifier       GeneralName OPTIONAL
}

END

Appendix F - Examples

   This chapter contains an example of a request and a response of a
   'Certify Claim of Possession of Data' transaction of the Clepsydre
   Demonstration Project sponsored by La Poste, France.

   The information has been formatted with a slightly modified version
   of Peter Gutmann's dumpasn1 program.



Adams, et al.                 Experimental                     [Page 34]

RFC 3029                     DVCS Protocols                February 2001


   The response Data Validation Certificate contains the signing
   certificate.

   The data that are time stamped is the binary of the client program
   used to make the request.

   Request:

   0 30  582: SEQUENCE {
   4 06    9:  OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
            : . (PKCS #7)
  15 A0  567:  [0] {
  19 30  563: . SEQUENCE {
  23 02    1: .  INTEGER 3
  26 31   11: .  SET {
  28 30    9: . . SEQUENCE {
  30 06    5: . .  OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
  37 05    0: . .  NULL
            : . .  }
            : . . }
  39 30  153: .  SEQUENCE {
  42 06   11: . . OBJECT IDENTIFIER
            : . .  id-ct-DVCSRequestData (1 2 840 113549 1 9 16 1 7)
            : . .  (S/MIME Content Types (1 2 840 113549 1 9 16 1))
  55 A0  137: . . [0] {
  58 04  134: . .  OCTET STRING, encapsulates {
  61 30  131: . . .  SEQUENCE {
  64 30   96: . . . . SEQUENCE {
  66 0A    1: . . . .  ENUMERATED CCPD (4)
  69 A0   77: . . . .  [0] {
  71 A4   75: . . . . . [4] {
  73 30   73: . . . . .  SEQUENCE {
  75 31   11: . . . . . . SET {
  77 30    9: . . . . . .  SEQUENCE {
  79 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  countryName (2 5 4 6)
            : . . . . . . .  (X.520 id-at (2 5 4))
  84 13    2: . . . . . . . PrintableString 'FR'
            : . . . . . . . }
            : . . . . . .  }
  88 31   14: . . . . . . SET {
  90 30   12: . . . . . .  SEQUENCE {
  92 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  localityName (2 5 4 7)
            : . . . . . . .  (X.520 id-at (2 5 4))
  97 13    5: . . . . . . . PrintableString 'Paris'
            : . . . . . . . }
            : . . . . . .  }



Adams, et al.                 Experimental                     [Page 35]

RFC 3029                     DVCS Protocols                February 2001


 104 31   16: . . . . . . SET {
 106 30   14: . . . . . .  SEQUENCE {
 108 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  organizationName (2 5 4 10)
            : . . . . . . .  (X.520 id-at (2 5 4))
 113 13    7: . . . . . . . PrintableString 'EdelWeb'
            : . . . . . . . }
            : . . . . . .  }
 122 31   24: . . . . . . SET {
 124 30   22: . . . . . .  SEQUENCE {
 126 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  commonName (2 5 4 3)
            : . . . . . . .  (X.520 id-at (2 5 4))
 131 13   15: . . . . . . . PrintableString 'Peter Sylvester'
            : . . . . . . . }
            : . . . . . .  }
            : . . . . . . }
            : . . . . .  }
            : . . . . . }
 148 A1   12: . . . .  [1] {
 150 06   10: . . . . . OBJECT IDENTIFIER '1 3 6 1 4 1 5309 1 2 1'
            : . . . . . }
            : . . . .  }
 162 30   31: . . . . SEQUENCE {
 164 30    7: . . . .  SEQUENCE {
 166 06    5: . . . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            : . . . . .  (OIW)
            : . . . . . }
 173 04   20: . . . .  OCTET STRING
            : . . . .  75 B6 85 AF 6F 89 46 7D E8 07 15 25 1E 45 97 8F
            : . . . .  CD 1F A5 66
            : . . . .  }
            : . . . . }
            : . . .  }
            : . .  }
            : . . }
 195 31  387: .  SET {
 199 30  383: . . SEQUENCE {
 203 02    1: . .  INTEGER 1
 206 30  124: . .  SEQUENCE {
 208 30  112: . . . SEQUENCE {
 210 31   11: . . .  SET {
 212 30    9: . . . . SEQUENCE {
 214 06    3: . . . .  OBJECT IDENTIFIER countryName (2 5 4 6)
            : . . . . . (X.520 id-at (2 5 4))
 219 13    2: . . . .  PrintableString 'FR'
            : . . . .  }
            : . . . . }



Adams, et al.                 Experimental                     [Page 36]

RFC 3029                     DVCS Protocols                February 2001


 223 31   21: . . .  SET {
 225 30   19: . . . . SEQUENCE {
 227 06    3: . . . .  OBJECT IDENTIFIER organizationName (2 5 4 10)
            : . . . . . (X.520 id-at (2 5 4))
 232 13   12: . . . .  PrintableString 'EdelWeb S.A.'
            : . . . .  }
            : . . . . }
 246 31   40: . . .  SET {
 248 30   38: . . . . SEQUENCE {
 250 06    3: . . . .  OBJECT IDENTIFIER
            : . . . . . organizationalUnitName (2 5 4 11)
            : . . . . . (X.520 id-at (2 5 4))
 255 13 31: . . . .  PrintableString 'Clepsydre Demonstration Service'
            : . . . .  }
            : . . . . }
 288 31   32: . . .  SET {
 290 30   30: . . . . SEQUENCE {
 292 06    3: . . . .  OBJECT IDENTIFIER commonName (2 5 4 3)
            : . . . . . (X.520 id-at (2 5 4))
 297 13   23: . . . .  PrintableString 'Time Stamping Authority'
            : . . . .  }
            : . . . . }
            : . . .  }
 322 02    8: . . . INTEGER
            : . . .  00 94 88 17 21 34 37 76
            : . . . }
 332 30    9: . .  SEQUENCE {
 334 06    5: . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            : . . .  (OIW)
 341 05    0: . . . NULL
            : . . . }
 343 A0   95: . .  [0] {
 345 30   26: . . . SEQUENCE {
 347 06    9: . . .  OBJECT IDENTIFIER
            : . . . . contentType (1 2 840 113549 1 9 3)
            : . . . . (PKCS #9 (1 2 840 113549 1 9))
 358 31   13: . . .  SET {
 360 06   11: . . . . OBJECT IDENTIFIER
            : . . . .  id-ct-dvcsrequest (1 2 840 113549 1 9 16 1 7)
            : . . . .  (S/MIME Content Types (1 2 840 113549 1 9 16 1))
            : . . . . }
            : . . .  }
 373 30   28: . . . SEQUENCE {
 375 06    9: . . .  OBJECT IDENTIFIER
            : . . . . signingTime (1 2 840 113549 1 9 5)
            : . . . . (PKCS #9 (1 2 840 113549 1 9))
 386 31   15: . . .  SET {
 388 17   13: . . . . UTCTime '000417171457Z'



Adams, et al.                 Experimental                     [Page 37]

RFC 3029                     DVCS Protocols                February 2001


            : . . . . }
            : . . .  }
 403 30   35: . . . SEQUENCE {
 405 06    9: . . .  OBJECT IDENTIFIER
            : . . . . messageDigest (1 2 840 113549 1 9 4)
            : . . . . (PKCS #9 (1 2 840 113549 1 9))
 416 31   22: . . .  SET {
 418 04   20: . . . . OCTET STRING
            : . . . .  4D A8 C2 D2 CE 7C 0D 04 41 2F 44 13 33 75 DB 2F
            : . . . .  5B 2D F9 DC
            : . . . . }
            : . . .  }
            : . . . }
 440 30   13: . .  SEQUENCE {
 442 06    9: . . . OBJECT IDENTIFIER
            : . . .  rsaEncryption (1 2 840 113549 1 1 1)
            : . . .  (PKCS #1)
 453 05    0: . . . NULL
            : . . . }
 455 04  128: . .  OCTET STRING
            : . . . 6E 7B 0E 36 F5 08 5F 16 3C 31 7B 28 BB 0B C2 C6
            : . . . 17 67 A6 B5 54 F1 98 E2 6F 89 96 0E 0C 99 E6 CB
            : . . . 40 C1 9B 8D D8 D7 8E D3 2B 41 F7 16 26 5B B7 08
            : . . . BF E6 95 B2 D9 01 6C FE B1 2C 52 C1 5A D2 31 F3
            : . . . 8E CA DD 11 A1 72 05 29 41 6A DD 28 40 AA 5C 77
            : . . . C6 9D 1D 80 53 DB 6F 9C 4C A5 A3 8F 92 8B 18 3F
            : . . . D5 3A AD 01 87 69 C3 FD D3 D8 C3 D0 CA 6B E6 0D
            : . . . 4E 53 6E 50 20 99 7C 94 C2 44 25 1B 06 C0 99 96
            : . .  }
            : . . }
            : .  }
            : . }
            :  }

The corresponding data in PEM format are:

-----BEGIN PKCS7-----
MIICRgYJKoZIhvcNAQcCoIICNzCCAjMCAQMxCzAJBgUrDgMCGgUAMIGZBgsqhkiG
9w0BCRABB6CBiQSBhjCBgzBgCgEEoE2kSzBJMQswCQYDVQQGEwJGUjEOMAwGA1UE
BxMFUGFyaXMxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAMTD1BldGVyIFN5bHZl
c3RlcqEMBgorBgEEAak9AQIBMB8wBwYFKw4DAhoEFHW2ha9viUZ96AcVJR5Fl4/N
H6VmMYIBgzCCAX8CAQEwfDBwMQswCQYDVQQGEwJGUjEVMBMGA1UEChMMRWRlbFdl
YiBTLkEuMSgwJgYDVQQLEx9DbGVwc3lkcmUgRGVtb25zdHJhdGlvbiBTZXJ2aWNl
MSAwHgYDVQQDExdUaW1lIFN0YW1waW5nIEF1dGhvcml0eQIIAJSIFyE0N3YwCQYF
Kw4DAhoFAKBfMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABBzAcBgkqhkiG9w0B
CQUxDxcNMDAwNDE3MTcxNDU3WjAjBgkqhkiG9w0BCQQxFgQUTajC0s58DQRBL0QT
M3XbL1st+dwwDQYJKoZIhvcNAQEBBQAEgYBuew429QhfFjwxeyi7C8LGF2emtVTx
mOJviZYODJnmy0DBm43Y147TK0H3FiZbtwi/5pWy2QFs/rEsUsFa0jHzjsrdEaFy



Adams, et al.                 Experimental                     [Page 38]

RFC 3029                     DVCS Protocols                February 2001


BSlBat0oQKpcd8adHYBT22+cTKWjj5KLGD/VOq0Bh2nD/dPYw9DKa+YNTlNuUCCZ
fJTCRCUbBsCZlg==
-----END PKCS7-----

Response:

   0 30 2039: SEQUENCE {
   4 06    9:  OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
            : . (PKCS #7)
  15 A0 2024:  [0] {
  19 30 2020: . SEQUENCE {
  23 02    1: .  INTEGER 3
  26 31   11: .  SET {
  28 30    9: . . SEQUENCE {
  30 06    5: . .  OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            : . . . (OIW)
  37 05    0: . .  NULL
            : . .  }
            : . . }
  39 30  301: .  SEQUENCE {
  43 06   11: . . OBJECT IDENTIFIER
            : . .  id-ct-DVCSResponseData (1 2 840 113549 1 9 16 1 8)
            : . .  (S/MIME Content Types (1 2 840 113549 1 9 16 1))
  56 A0  284: . . [0] {
  60 04  280: . .  OCTET STRING, encapsulates {
  64 30  276: . . .  SEQUENCE {
  68 30  214: . . . . SEQUENCE {
  71 0A    1: . . . .  ENUMERATED CCPD (4)
  74 A0   77: . . . .  [0] {
  76 A4   75: . . . . . [4] {
  78 30   73: . . . . .  SEQUENCE {
  80 31   11: . . . . . . SET {
  82 30    9: . . . . . .  SEQUENCE {
  84 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  countryName (2 5 4 6)
            : . . . . . . .  (X.520 id-at (2 5 4))
  89 13    2: . . . . . . . PrintableString 'FR'
            : . . . . . . . }
            : . . . . . .  }
  93 31   14: . . . . . . SET {
  95 30   12: . . . . . .  SEQUENCE {
  97 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  localityName (2 5 4 7)
            : . . . . . . .  (X.520 id-at (2 5 4))
 102 13    5: . . . . . . . PrintableString 'Paris'
            : . . . . . . . }
            : . . . . . .  }
 109 31   16: . . . . . . SET {



Adams, et al.                 Experimental                     [Page 39]

RFC 3029                     DVCS Protocols                February 2001


 111 30   14: . . . . . .  SEQUENCE {
 113 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  organizationName (2 5 4 10)
            : . . . . . . .  (X.520 id-at (2 5 4))
 118 13    7: . . . . . . . PrintableString 'EdelWeb'
            : . . . . . . . }
            : . . . . . .  }
 127 31   24: . . . . . . SET {
 129 30   22: . . . . . .  SEQUENCE {
 131 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  commonName (2 5 4 3)
            : . . . . . . .  (X.520 id-at (2 5 4))
 136 13   15: . . . . . . . PrintableString 'Peter Sylvester'
            : . . . . . . . }
            : . . . . . .  }
            : . . . . . . }
            : . . . . .  }
            : . . . . . }
 153 A1   12: . . . .  [1] {
 155 06   10: . . . . . OBJECT IDENTIFIER '1 3 6 1 4 1 5309 1 2 1'
            : . . . . . }
 167 A2  116: . . . .  [2] {
 169 A4  114: . . . . . [4] {
 171 30  112: . . . . .  SEQUENCE {
 173 31   11: . . . . . . SET {
 175 30    9: . . . . . .  SEQUENCE {
 177 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  countryName (2 5 4 6)
            : . . . . . . .  (X.520 id-at (2 5 4))
 182 13    2: . . . . . . . PrintableString 'FR'
            : . . . . . . . }
            : . . . . . .  }
 186 31   21: . . . . . . SET {
 188 30   19: . . . . . .  SEQUENCE {
 190 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  organizationName (2 5 4 10)
            : . . . . . . .  (X.520 id-at (2 5 4))
 195 13   12: . . . . . . . PrintableString 'EdelWeb S.A.'
            : . . . . . . . }
            : . . . . . .  }
 209 31   40: . . . . . . SET {
 211 30   38: . . . . . .  SEQUENCE {
 213 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  organizationalUnitName (2 5 4 11)
            : . . . . . . .  (X.520 id-at (2 5 4))
 218 13 31: . . . . . PrintableString 'Clepsydre Demonstration Service'
            : . . . . . . . }
            : . . . . . .  }



Adams, et al.                 Experimental                     [Page 40]

RFC 3029                     DVCS Protocols                February 2001


 251 31   32: . . . . . . SET {
 253 30   30: . . . . . .  SEQUENCE {
 255 06    3: . . . . . . . OBJECT IDENTIFIER
            : . . . . . . .  commonName (2 5 4 3)
            : . . . . . . .  (X.520 id-at (2 5 4))
 260 13   23: . . . . . . . PrintableString 'Time Stamping Authority'
            : . . . . . . . }
            : . . . . . .  }
            : . . . . . . }
            : . . . . .  }
            : . . . . . }
            : . . . .  }
 285 30   31: . . . . SEQUENCE {
 287 30    7: . . . .  SEQUENCE {
 289 06    5: . . . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            : . . . . . }
 296 04   20: . . . .  OCTET STRING
            : . . . .  75 B6 85 AF 6F 89 46 7D E8 07 15 25 1E 45 97 8F
            : . . . .  CD 1F A5 66
            : . . . .  }
 318 02    7: . . . . INTEGER
            : . . . .  01 78 0A 1E CA 88 23
 327 18   15: . . . . GeneralizedTime '20000417171617Z'
            : . . . . }
            : . . .  }
            : . .  }
            : . . }
 344 A0  992: .  [0] {
 348 30  988: . . SEQUENCE {
 352 30  708: . .  SEQUENCE {
 356 A0    3: . . . [0] {
 358 02    1: . . .  INTEGER 2
            : . . .  }
 361 02    8: . . . INTEGER
            : . . .  00 94 88 17 17 64 37 32
 371 30   13: . . . SEQUENCE {
 373 06    9: . . .  OBJECT IDENTIFIER
            : . . . . md5withRSAEncryption (1 2 840 113549 1 1 4)
            : . . . . (PKCS #1)
 384 05    0: . . .  NULL
            : . . .  }
 386 30  112: . . . SEQUENCE {
 388 31   11: . . .  SET {
 390 30    9: . . . . SEQUENCE {
 392 06    3: . . . .  OBJECT IDENTIFIER countryName (2 5 4 6)
            : . . . . . (X.520 id-at (2 5 4))
 397 13    2: . . . .  PrintableString 'FR'
            : . . . .  }



Adams, et al.                 Experimental                     [Page 41]

RFC 3029                     DVCS Protocols                February 2001


            : . . . . }
 401 31   21: . . .  SET {
 403 30   19: . . . . SEQUENCE {
 405 06    3: . . . .  OBJECT IDENTIFIER organizationName (2 5 4 10)
            : . . . . . (X.520 id-at (2 5 4))
 410 13   12: . . . .  PrintableString 'EdelWeb S.A.'
            : . . . .  }
            : . . . . }
 424 31   40: . . .  SET {
 426 30   38: . . . . SEQUENCE {
 428 06    3: . . . .  OBJECT IDENTIFIER
            : . . . . . organizationalUnitName (2 5 4 11)
            : . . . . . (X.520 id-at (2 5 4))
 433 13 31: . . . .  PrintableString 'Clepsydre Demonstration Service'
            : . . . .  }
            : . . . . }
 466 31   32: . . .  SET {
 468 30   30: . . . . SEQUENCE {
 470 06    3: . . . .  OBJECT IDENTIFIER commonName (2 5 4 3)
            : . . . . . (X.520 id-at (2 5 4))
 475 13   23: . . . .  PrintableString 'Time Stamping Authority'
            : . . . .  }
            : . . . . }
            : . . .  }
 500 30   30: . . . SEQUENCE {
 502 17   13: . . .  UTCTime '000125161938Z'
 517 17   13: . . .  UTCTime '200120161938Z'
            : . . .  }
 532 30  112: . . . SEQUENCE {
 534 31   11: . . .  SET {
 536 30    9: . . . . SEQUENCE {
 538 06    3: . . . .  OBJECT IDENTIFIER countryName (2 5 4 6)
            : . . . . . (X.520 id-at (2 5 4))
 543 13    2: . . . .  PrintableString 'FR'
            : . . . .  }
            : . . . . }
 547 31   21: . . .  SET {
 549 30   19: . . . . SEQUENCE {
 551 06    3: . . . .  OBJECT IDENTIFIER organizationName (2 5 4 10)
            : . . . . . (X.520 id-at (2 5 4))
 556 13   12: . . . .  PrintableString 'EdelWeb S.A.'
            : . . . .  }
            : . . . . }
 570 31   40: . . .  SET {
 572 30   38: . . . . SEQUENCE {
 574 06    3: . . . .  OBJECT IDENTIFIER
            : . . . . . organizationalUnitName (2 5 4 11)
            : . . . . . (X.520 id-at (2 5 4))



Adams, et al.                 Experimental                     [Page 42]

RFC 3029                     DVCS Protocols                February 2001


 579 13 31: . . . .  PrintableString 'Clepsydre Demonstration Service'
            : . . . .  }
            : . . . . }
 612 31   32: . . .  SET {
 614 30   30: . . . . SEQUENCE {
 616 06    3: . . . .  OBJECT IDENTIFIER commonName (2 5 4 3)
            : . . . . . (X.520 id-at (2 5 4))
 621 13   23: . . . .  PrintableString 'Time Stamping Authority'
            : . . . .  }
            : . . . . }
            : . . .  }
 646 30  290: . . . SEQUENCE {
 650 30   13: . . .  SEQUENCE {
 652 06    9: . . . . OBJECT IDENTIFIER
            : . . . .  rsaEncryption (1 2 840 113549 1 1 1)
            : . . . .  (PKCS #1)
 663 05    0: . . . . NULL
            : . . . . }
 665 03  271: . . .  BIT STRING 0 unused bits
            : . . . . 30 82 01 0A 02 82 01 01 00 FA C3 17 AE EB B7 9D
            : . . . . EB AB BD 05 7E 39 43 6D 04 45 58 74 05 A5 CC F3
            : . . . . 6C 2F 8C 8E 77 7E C2 9F 12 11 5C 7D DB BE 23 28
            : . . . . 9A 90 D2 AB C6 A2 BA BD A3 7E 99 A6 99 21 A5 D8
            : . . . . 90 B9 CF A7 23 4E A0 56 A0 C1 0A 46 89 8E 3C 91
            : . . . . 67 37 FD 9B AB 49 17 FC 4A A5 F2 E4 4C 6E E3 6A
            : . . . . 1C 92 97 04 6F 7F 0C 5C FB 74 CB 95 7E 4C C3 58
            : . . . . 12 E8 A9 D6 F0 DD 12 44 15 E7 8B 2E AF 51 C0 0C
            : . . . . . . [ Another 142 bytes skipped ]
            : . . .  }
 940 A3  122: . . . [3] {
 942 30  120: . . .  SEQUENCE {
 944 30   15: . . . . SEQUENCE {
 946 06    3: . . . .  OBJECT IDENTIFIER basicConstraints (2 5 29 19)
            : . . . . . (X.509 id-ce (2 5 29))
 951 04    8: . . . .  OCTET STRING, encapsulates {
 953 30    6: . . . . .  SEQUENCE {
 955 01    1: . . . . . . BOOLEAN TRUE
 958 02    1: . . . . . . INTEGER 0
            : . . . . . . }
            : . . . . .  }
            : . . . .  }
 961 30   22: . . . . SEQUENCE {
 963 06    3: . . . .  OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
            : . . . . . (X.509 id-ce (2 5 29))
 968 01    1: . . . .  BOOLEAN TRUE
 971 04   12: . . . .  OCTET STRING, encapsulates {
 973 30   10: . . . . .  SEQUENCE {
 975 06    8: . . . . . . OBJECT IDENTIFIER '1 3 6 1 5 5 7 3 10'



Adams, et al.                 Experimental                     [Page 43]

RFC 3029                     DVCS Protocols                February 2001


            : . . . . . . }
            : . . . . .  }
            : . . . .  }
 985 30   77: . . . . SEQUENCE {
 987 06    8: . . . .  OBJECT IDENTIFIER
            : . . . . . authorityInfoAccess (1 3 6 1 5 5 7 1 1)
            : . . . . . (PKIX private extension)
 997 01    1: . . . .  BOOLEAN TRUE
1000 04   62: . . . .  OCTET STRING, encapsulates {
1002 30   60: . . . . .  SEQUENCE {
1004 30   58: . . . . . . SEQUENCE {
1006 06    8: . . . . . .  OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 4'
1016 86   46: . . . . . .  [6]
            : . . . .  'https://clepsydre.edelweb.fr/dvcs/service-ccpd'
            : . . . . . .  }
            : . . . . . . }
            : . . . . .  }
            : . . . .  }
            : . . . . }
            : . . .  }
            : . . . }
1064 30   13: . .  SEQUENCE {
1066 06    9: . . . OBJECT IDENTIFIER
            : . . .  md5withRSAEncryption (1 2 840 113549 1 1 4)
            : . . .  (PKCS #1)
1077 05    0: . . . NULL
            : . . . }
1079 03  257: . .  BIT STRING 0 unused bits
            : . . . 08 DA AF 5B 09 39 66 D3 BE 80 1D D7 72 B5 2C A3
            : . . . 04 FB 46 F8 05 F5 BF 83 F3 6D 6D 32 28 1C 46 EE
            : . . . 0F EA 30 61 8A 1E 8A 03 4E 98 81 60 1F 97 17 53
            : . . . D1 54 73 3F 72 98 45 D3 10 9A D3 77 B8 74 0E 9A
            : . . . 90 29 8E AC A4 EB D2 24 6D F6 21 1D 3F 52 8B 2C
            : . . . E6 92 E7 52 C6 54 93 91 BC 57 74 21 38 39 75 CD
            : . . . 30 49 54 13 94 6C FE F1 64 38 1F 5F 7D BB E0 3E
            : . . . A8 F1 28 1C F1 D9 28 FA 32 1E 3B 48 BF 5C 70 21
            : . . . . . [ Another 128 bytes skipped ]
            : . .  }
            : . . }
1340 31  699: .  SET {
1344 30  695: . . SEQUENCE {
1348 02    1: . .  INTEGER 1
1351 30  124: . .  SEQUENCE {
1353 30  112: . . . SEQUENCE {
1355 31   11: . . .  SET {
1357 30    9: . . . . SEQUENCE {
1359 06    3: . . . .  OBJECT IDENTIFIER countryName (2 5 4 6)
            : . . . . . (X.520 id-at (2 5 4))



Adams, et al.                 Experimental                     [Page 44]

RFC 3029                     DVCS Protocols                February 2001


1364 13    2: . . . .  PrintableString 'FR'
            : . . . .  }
            : . . . . }
1368 31   21: . . .  SET {
1370 30   19: . . . . SEQUENCE {
1372 06    3: . . . .  OBJECT IDENTIFIER organizationName (2 5 4 10)
            : . . . . . (X.520 id-at (2 5 4))
1377 13   12: . . . .  PrintableString 'EdelWeb S.A.'
            : . . . .  }
            : . . . . }
1391 31   40: . . .  SET {
1393 30   38: . . . . SEQUENCE {
1395 06    3: . . . .  OBJECT IDENTIFIER
            : . . . . . organizationalUnitName (2 5 4 11)
            : . . . . . (X.520 id-at (2 5 4))
1400 13 31: . . . .  PrintableString 'Clepsydre Demonstration Service'
            : . . . .  }
            : . . . . }
1433 31   32: . . .  SET {
1435 30   30: . . . . SEQUENCE {
1437 06    3: . . . .  OBJECT IDENTIFIER commonName (2 5 4 3)
            : . . . . . (X.520 id-at (2 5 4))
1442 13   23: . . . .  PrintableString 'Time Stamping Authority'
            : . . . .  }
            : . . . . }
            : . . .  }
1467 02    8: . . . INTEGER
            : . . .  00 94 88 25 72 35 27 50
            : . . . }
1477 30    9: . .  SEQUENCE {
1479 06    5: . . . OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
            : . . .  (OIW)
1486 05    0: . . . NULL
            : . . . }
1488 A0  276: . .  [0] {
1492 30   26: . . . SEQUENCE {
1494 06    9: . . .  OBJECT IDENTIFIER
            : . . . . contentType (1 2 840 113549 1 9 3)
            : . . . . (PKCS #9 (1 2 840 113549 1 9))
1505 31   13: . . .  SET {
1507 06   11: . . . . OBJECT IDENTIFIER
            : . . . .  id-ct-dvcsresponse (1 2 840 113549 1 9 16 1 8)
            : . . . .  (S/MIME Content Types (1 2 840 113549 1 9 16 1))
            : . . . . }
            : . . .  }
1520 30   28: . . . SEQUENCE {
1522 06    9: . . .  OBJECT IDENTIFIER
            : . . . . signingTime (1 2 840 113549 1 9 5)



Adams, et al.                 Experimental                     [Page 45]

RFC 3029                     DVCS Protocols                February 2001


            : . . . . (PKCS #9 (1 2 840 113549 1 9))
1533 31   15: . . .  SET {
1535 17   13: . . . . UTCTime '000417171619Z'
            : . . . . }
            : . . .  }
1550 30   35: . . . SEQUENCE {
1552 06    9: . . .  OBJECT IDENTIFIER
            : . . . . messageDigest (1 2 840 113549 1 9 4)
            : . . . . (PKCS #9 (1 2 840 113549 1 9))
1563 31   22: . . .  SET {
1565 04   20: . . . . OCTET STRING
            : . . . .  68 50 DC 90 20 2E C2 F0 55 15 7F 77 A9 A6 0C 34
            : . . . .  CC 13 06 FA
            : . . . . }
            : . . .  }
1587 30  178: . . . SEQUENCE {
1590 06   11: . . .  OBJECT IDENTIFIER
          : . . . id-aa-signingCertificate (1 2 840 113549 1 9 16 2 12)
      : . . (S/MIME Authenticated Attributes (1 2 840 113549 1 9 16 2))
1603 31  162: . . .  SET {
1606 30  159: . . . . SEQUENCE {
1609 30  156: . . . .  SEQUENCE {
1612 30  153: . . . . . SEQUENCE {
1615 04   20: . . . . .  OCTET STRING
            : . . . .  5C F1 18 F3 4A CA B4 67 D6 D8 E7 F8 3B 4A D9 7A
            : . . . .  32 A5 43 A5
1637 30  128: . . . . .  SEQUENCE {
1640 30  116: . . . . . . SEQUENCE {
1642 A4  114: . . . . . .  [4] {
1644 30  112: . . . . . . . SEQUENCE {
1646 31   11: . . . . . . .  SET {
1648 30    9: . . . . . . . . SEQUENCE {
1650 06    3: . . . . . . . .  OBJECT IDENTIFIER
            : . . . . . . . . . countryName (2 5 4 6)
            : . . . . . . . . . (X.520 id-at (2 5 4))
1655 13    2: . . . . . . . .  PrintableString 'FR'
            : . . . . . . . .  }
            : . . . . . . . . }
1659 31   21: . . . . . . .  SET {
1661 30   19: . . . . . . . . SEQUENCE {
1663 06    3: . . . . . . . .  OBJECT IDENTIFIER
            : . . . . . . . . . organizationName (2 5 4 10)
            : . . . . . . . . . (X.520 id-at (2 5 4))
1668 13   12: . . . . . . . .  PrintableString 'EdelWeb S.A.'
            : . . . . . . . .  }
            : . . . . . . . . }
1682 31   40: . . . . . . .  SET {
1684 30   38: . . . . . . . . SEQUENCE {



Adams, et al.                 Experimental                     [Page 46]

RFC 3029                     DVCS Protocols                February 2001


1686 06    3: . . . . . . . .  OBJECT IDENTIFIER
            : . . . . . . . . . organizationalUnitName (2 5 4 11)
            : . . . . . . . . . (X.520 id-at (2 5 4))
1691 13 31: . . . . .PrintableString 'Clepsydre Demonstration Service'
            : . . . . . . . .  }
            : . . . . . . . . }
1724 31   32: . . . . . . .  SET {
1726 30   30: . . . . . . . . SEQUENCE {
1728 06    3: . . . . . . . .  OBJECT IDENTIFIER
            : . . . . . . . . . commonName (2 5 4 3)
            : . . . . . . . . . (X.520 id-at (2 5 4))
1733 13 23: . . . . . . . .  PrintableString 'Time Stamping Authority'
            : . . . . . . . .  }
            : . . . . . . . . }
            : . . . . . . .  }
            : . . . . . . . }
            : . . . . . .  }
1758 02    8: . . . . . . INTEGER
            : . . . .  00 94 88 25 72 35 27 50
            : . . . . . . }
            : . . . . .  }
            : . . . . . }
            : . . . .  }
            : . . . . }
            : . . .  }
            : . . . }
1768 30   13: . .  SEQUENCE {
1770 06    9: . . . OBJECT IDENTIFIER
            : . . .  rsaEncryption (1 2 840 113549 1 1 1)
            : . . .  (PKCS #1)
1781 05    0: . . . NULL
            : . . . }
1783 04  256: . .  OCTET STRING
            : . . . 2E 70 9F 56 5E 01 56 A9 E1 47 81 12 35 21 29 09
            : . . . 16 7A ED 45 F9 5A A2 ED E4 FE 9D 2C E4 DA 12 66
            : . . . 62 14 59 61 8B 50 7B 01 82 3D BD 7E E6 38 D0 A8
            : . . . A0 37 98 79 13 26 39 29 C6 72 20 A9 95 71 E7 53
            : . . . 7F 79 77 98 EF 23 02 4E B9 BD 90 9B AC 05 A2 70
            : . . . 8F 3A 42 36 9C 2C B0 94 B1 2B 0B 36 94 0E 78 0E
            : . . . B0 D1 09 20 63 BC FF CD 32 F1 5A D3 AB 9F 93 9C
            : . . . 5A A3 58 99 A0 28 11 E0 80 4D 4D 1E 77 04 F4 50
            : . . . . . [ Another 128 bytes skipped ]
            : . .  }
            : . . }
            : .  }
            : . }
            :  }




Adams, et al.                 Experimental                     [Page 47]

RFC 3029                     DVCS Protocols                February 2001


The corresponding data in PEM format (together with a technical textual
description) are:

Data Validation Certificate:
    Request Information:
      Service: Certify Claim of Possession of Data - ccpd(4)
      Policy: EdelWeb Customer Policy Clepsydre
      Requester:
        DirName:/C=FR/L=Paris/O=EdelWeb/CN=Peter Sylvester
      DVCS:
        DirName:/C=FR/O=EdelWeb S.A./
  OU=Clepsydre Demonstration Service/CN=Time Stamping Authority
    SerialNumber: 01780a1eca8823
    MessageDigest:
      Algorithm: sha1
      Data     : 75B685AF6F89467DE80715251E45978FCD1FA566
    Asserted Time:
      Generalized Time: 17-Apr-2000 19:16:17 (Apr 17 17:16:17 2000 GMT)
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            94:88:17:17:64:37:32
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=FR, O=EdelWeb S.A.,
    OU=Clepsydre Demonstration Service, CN=Time Stamping Authority
        Validity
            Not Before: Jan 25 16:19:38 2000 GMT
            Not After : Jan 20 16:19:38 2020 GMT
        Subject: C=FR, O=EdelWeb S.A.,
    OU=Clepsydre Demonstration Service, CN=Time Stamping Authority
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    00:fa:c3:17:ae:eb:b7:9d:eb:ab:bd:05:7e:39:43:
                    6d:04:45:58:74:05:a5:cc:f3:6c:2f:8c:8e:77:7e:
                    c2:9f:12:11:5c:7d:db:be:23:28:9a:90:d2:ab:c6:
                    a2:ba:bd:a3:7e:99:a6:99:21:a5:d8:90:b9:cf:a7:
                    23:4e:a0:56:a0:c1:0a:46:89:8e:3c:91:67:37:fd:
                    9b:ab:49:17:fc:4a:a5:f2:e4:4c:6e:e3:6a:1c:92:
                    97:04:6f:7f:0c:5c:fb:74:cb:95:7e:4c:c3:58:12:
                    e8:a9:d6:f0:dd:12:44:15:e7:8b:2e:af:51:c0:0c:
                    5f:a8:65:fc:47:a1:c9:98:1f:d4:e1:ea:bc:1c:1a:
                    27:bb:8b:56:f1:12:55:10:f4:8e:d8:9f:19:9c:1e:
                    81:f7:db:63:dd:88:37:3f:71:79:5b:96:e2:5f:82:
                    d5:12:19:05:0d:e1:3d:a5:6d:66:e4:2c:1e:ed:c7:
                    4c:b8:df:aa:38:c8:15:6a:ae:25:7d:46:2a:07:f9:



Adams, et al.                 Experimental                     [Page 48]

RFC 3029                     DVCS Protocols                February 2001


                    83:77:c4:51:ee:90:dc:05:d0:c3:f0:f1:5f:e8:d4:
                    ed:5d:34:70:91:9d:9f:08:55:7d:5b:e5:8d:5f:35:
                    59:83:4e:72:19:bb:9c:88:d1:7a:fc:23:a5:84:99:
                    b4:17:8a:4d:6c:9d:d0:a6:35:80:5f:ca:fb:24:8b:
                    54:1d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:TRUE, pathlen:0
            X509v3 Extended Key Usage: critical
                DVCS Signing
            Authority Information Access: critical
         DVCS - URI:https://clepsydre.edelweb.fr/dvcs/service-ccpd

    Signature Algorithm: md5WithRSAEncryption
        08:da:af:5b:09:39:66:d3:be:80:1d:d7:72:b5:2c:a3:04:fb:
        46:f8:05:f5:bf:83:f3:6d:6d:32:28:1c:46:ee:0f:ea:30:61:
        8a:1e:8a:03:4e:98:81:60:1f:97:17:53:d1:54:73:3f:72:98:
        45:d3:10:9a:d3:77:b8:74:0e:9a:90:29:8e:ac:a4:eb:d2:24:
        6d:f6:21:1d:3f:52:8b:2c:e6:92:e7:52:c6:54:93:91:bc:57:
        74:21:38:39:75:cd:30:49:54:13:94:6c:fe:f1:64:38:1f:5f:
        7d:bb:e0:3e:a8:f1:28:1c:f1:d9:28:fa:32:1e:3b:48:bf:5c:
        70:21:29:ef:be:72:24:da:0d:f9:51:7a:fe:d7:f5:ff:e8:c2:
        ea:c6:4c:45:14:51:53:fd:00:d5:5b:cc:67:2a:23:94:31:9e:
        c2:90:38:9b:b0:df:f9:de:67:0c:57:5c:d7:b0:fc:f2:72:96:
        c4:d1:7a:9d:a0:e6:51:24:99:9e:89:c6:39:f9:72:7a:44:fd:
        2d:3f:bc:df:c7:25:27:94:a1:b5:7d:ba:06:75:67:1c:95:6c:
        bd:2c:74:41:3e:cd:cd:39:5c:2e:9c:c3:c3:09:e3:79:d5:eb:
        85:e8:f1:72:29:80:f6:c6:6e:61:1b:58:fc:87:3e:d9:e1:53:
        10:e0:b1:05

-----BEGIN PKCS7-----
MIIH9wYJKoZIhvcNAQcCoIIH6DCCB+QCAQMxCzAJBgUrDgMCGgUAMIIBLQYLKoZI
hvcNAQkQAQigggEcBIIBGDCCARQwgdYKAQSgTaRLMEkxCzAJBgNVBAYTAkZSMQ4w
DAYDVQQHEwVQYXJpczEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UEAxMPUGV0ZXIg
U3lsdmVzdGVyoQwGCisGAQQBqT0BAgGidKRyMHAxCzAJBgNVBAYTAkZSMRUwEwYD
VQQKEwxFZGVsV2ViIFMuQS4xKDAmBgNVBAsTH0NsZXBzeWRyZSBEZW1vbnN0cmF0
aW9uIFNlcnZpY2UxIDAeBgNVBAMTF1RpbWUgU3RhbXBpbmcgQXV0aG9yaXR5MB8w
BwYFKw4DAhoEFHW2ha9viUZ96AcVJR5Fl4/NH6VmAgcBeAoeyogjGA8yMDAwMDQx
NzE3MTYxN1qgggPgMIID3DCCAsSgAwIBAgIIAJSIFxdkNzIwDQYJKoZIhvcNAQEE
BQAwcDELMAkGA1UEBhMCRlIxFTATBgNVBAoTDEVkZWxXZWIgUy5BLjEoMCYGA1UE
CxMfQ2xlcHN5ZHJlIERlbW9uc3RyYXRpb24gU2VydmljZTEgMB4GA1UEAxMXVGlt
ZSBTdGFtcGluZyBBdXRob3JpdHkwHhcNMDAwMTI1MTYxOTM4WhcNMjAwMTIwMTYx
OTM4WjBwMQswCQYDVQQGEwJGUjEVMBMGA1UEChMMRWRlbFdlYiBTLkEuMSgwJgYD
VQQLEx9DbGVwc3lkcmUgRGVtb25zdHJhdGlvbiBTZXJ2aWNlMSAwHgYDVQQDExdU
aW1lIFN0YW1waW5nIEF1dGhvcml0eTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAPrDF67rt53rq70FfjlDbQRFWHQFpczzbC+Mjnd+wp8SEVx9274jKJqQ
0qvGorq9o36ZppkhpdiQuc+nI06gVqDBCkaJjjyRZzf9m6tJF/xKpfLkTG7jahyS



Adams, et al.                 Experimental                     [Page 49]

RFC 3029                     DVCS Protocols                February 2001


lwRvfwxc+3TLlX5Mw1gS6KnW8N0SRBXniy6vUcAMX6hl/EehyZgf1OHqvBwaJ7uL
VvESVRD0jtifGZwegffbY92INz9xeVuW4l+C1RIZBQ3hPaVtZuQsHu3HTLjfqjjI
FWquJX1GKgf5g3fEUe6Q3AXQw/DxX+jU7V00cJGdnwhVfVvljV81WYNOchm7nIjR
evwjpYSZtBeKTWyd0KY1gF/K+ySLVB0CAwEAAaN6MHgwDwYDVR0TBAgwBgEB/wIB
ADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDCjBNBggrBgEFBQcBAQEB/wQ+MDwwOgYI
KwYBBQUHMASGLmh0dHBzOi8vY2xlcHN5ZHJlLmVkZWx3ZWIuZnIvZHZjcy9zZXJ2
aWNlLWNjcGQwDQYJKoZIhvcNAQEEBQADggEBAAjar1sJOWbTvoAd13K1LKME+0b4
BfW/g/NtbTIoHEbuD+owYYoeigNOmIFgH5cXU9FUcz9ymEXTEJrTd7h0DpqQKY6s
pOvSJG32IR0/Uoss5pLnUsZUk5G8V3QhODl1zTBJVBOUbP7xZDgfX3274D6o8Sgc
8dko+jIeO0i/XHAhKe++ciTaDflRev7X9f/owurGTEUUUVP9ANVbzGcqI5QxnsKQ
OJuw3/neZwxXXNew/PJylsTRep2g5lEkmZ6Jxjn5cnpE/S0/vN/HJSeUobV9ugZ1
ZxyVbL0sdEE+zc05XC6cw8MJ43nV64Xo8XIpgPbGbmEbWPyHPtnhUxDgsQUxggK7
MIICtwIBATB8MHAxCzAJBgNVBAYTAkZSMRUwEwYDVQQKEwxFZGVsV2ViIFMuQS4x
KDAmBgNVBAsTH0NsZXBzeWRyZSBEZW1vbnN0cmF0aW9uIFNlcnZpY2UxIDAeBgNV
BAMTF1RpbWUgU3RhbXBpbmcgQXV0aG9yaXR5AggAlIglcjUnUDAJBgUrDgMCGgUA
oIIBFDAaBgkqhkiG9w0BCQMxDQYLKoZIhvcNAQkQAQgwHAYJKoZIhvcNAQkFMQ8X
DTAwMDQxNzE3MTYxOVowIwYJKoZIhvcNAQkEMRYEFGhQ3JAgLsLwVRV/d6mmDDTM
Ewb6MIGyBgsqhkiG9w0BCRACDDGBojCBnzCBnDCBmQQUXPEY80rKtGfW2Of4O0rZ
ejKlQ6UwgYAwdKRyMHAxCzAJBgNVBAYTAkZSMRUwEwYDVQQKEwxFZGVsV2ViIFMu
QS4xKDAmBgNVBAsTH0NsZXBzeWRyZSBEZW1vbnN0cmF0aW9uIFNlcnZpY2UxIDAe
BgNVBAMTF1RpbWUgU3RhbXBpbmcgQXV0aG9yaXR5AggAlIglcjUnUDANBgkqhkiG
9w0BAQEFAASCAQAucJ9WXgFWqeFHgRI1ISkJFnrtRflaou3k/p0s5NoSZmIUWWGL
UHsBgj29fuY40KigN5h5EyY5KcZyIKmVcedTf3l3mO8jAk65vZCbrAWicI86Qjac
LLCUsSsLNpQOeA6w0QkgY7z/zTLxWtOrn5OcWqNYmaAoEeCATU0edwT0UAfVi1Sg
IzL/ppziurjbVUfJyLoH75AUSKi2xXzVqSB0HFbvjxuz/IdtgfHUbxqHMJJHaeB5
4LwQmc9NNkw2A1Fy0VumHi2G8R8K6L/rOPnOGuywj1GuKjtGhL9NjJ/uH+/FNaNj
vjjAA3w6XrjPOxgQiNu7T3j2++QcjdT4++tQ
-----END PKCS7-----

Appendix G - Acknowledgements

   This document is based on two initial works from Robert Zuccherato
   and Carlisle Adams, both at Entrust Technologies, for time stamping
   and for notary and data certification services.

   Thanks to Denis Pinkas, Bull and Bruno Salgueiro, SIBS for valuable
   comments.














Adams, et al.                 Experimental                     [Page 50]

RFC 3029                     DVCS Protocols                February 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Adams, et al.                 Experimental                     [Page 51]