File: rfc2802.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 (1627 lines) | stat: -rw-r--r-- 52,756 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






Network Working Group                                        K. Davidson
Request for Comments: 2802                                  Differential
Category: Informational                                     Y. Kawatsura
                                                                 Hitachi
                                                              April 2000


 Digital Signatures for the v1.0 Internet Open Trading Protocol (IOTP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

   A syntax and procedures are described for the computation and
   verification of digital signatures for use within Version 1.0 of the
   Internet Open Trading Protocol (IOTP).

Acknowledgment

   This document is based on work originally done on general XML digital
   signatures by:

     Richard Brown of GlobeSet, Inc. <rdbrown@GlobeSet.com>

   Other contributors to the design of the IOTP DSIG DTD include, in
   alphabetic order:

     David Burdett, Commerce One
     Andrew Drapp, Hitachi
     Donald Eastlake 3rd, Motorola, Inc.













Davidson & Kawatsura         Informational                      [Page 1]

RFC 2802              Digital Signatures for IOTP             April 2000


Table of Contents

   1. Introduction............................................3
   2. Objective and Requirements..............................3
   3. Signature Basics........................................3
   3.1 Signature Element......................................3
   3.2 Digest Element.........................................4
   3.3 Originator and Recipient Information Elements..........5
   3.4 Algorithm Element......................................5
   4. Detailed Signature Syntax...............................6
   4.1 Uniform Resource Names.................................6
   4.2 IotpSignatures.........................................6
   4.3 Signature Component....................................6
   4.3.1 Signature............................................6
   4.3.2 Manifest.............................................7
   4.3.3 Algorithm............................................9
   4.3.4 Digest...............................................9
   4.3.5 Attribute...........................................10
   4.3.6 OriginatorInfo......................................11
   4.3.7 RecipientInfo.......................................11
   4.3.8 KeyIdentifier.......................................12
   4.3.9 Parameter...........................................13
   4.4 Certificate Component.................................13
   4.4.1 Certificate.........................................13
   4.4.2 IssuerAndSerialNumber...............................14
   4.5 Common Components.....................................15
   4.5.1 Value...............................................15
   4.5.2 Locator.............................................15
   5. Supported Algorithms...................................16
   5.1 Digest Algorithms.....................................16
   5.1.1 SHA1................................................16
   5.1.2 DOM-HASH............................................17
   5.2 Signature Algorithms..................................17
   5.2.1 DSA.................................................17
   5.2.2 HMAC................................................18
   5.2.3 RSA.................................................20
   5.2.4 ECDSA...............................................20
   6. Examples...............................................21
   7. Signature DTD..........................................23
   8. Security Considerations................................25
   References................................................26
   Authors' Addresses........................................28
   Full Copyright Statement..................................29








Davidson & Kawatsura         Informational                      [Page 2]

RFC 2802              Digital Signatures for IOTP             April 2000


1. Introduction

   The Internet Open Trading Protocol (IOTP) provides a payment system
   independent interoperable framework for Internet commerce as
   documented in [RFC 2801]. All IOTP messages are XML documents. XML,
   the Extensible Markup Language [XML], is a syntactical standard
   promulgated by the World Wide Web Consortium. XML is intended
   primarily for structuring data exchanged and served over the World
   Wide Web.

   Although IOTP assumes that any payment system used with it provides
   its own security, there are numerous cases where IOTP requires
   authentication and integrity services for portions of the XML
   messages it specifies.

2. Objective and Requirements

   This document covers how digital signatures may be used with XML
   documents to provide authentication and tamper-proof protocol
   messages specifically for Version 1.0 of the IOTP protocol. The
   reader should recognize that an effort towards general XML digital
   signatures exists but is unlikely to produce its final result in time
   for IOTP Version 1.0.  Future versions of IOTP will probably adopt by
   reference the results of this general XML digital signature effort.

   The objective of this document is to propose syntax and procedures
   for the computation and verification of digital signatures applicable
   to Version 1.0 IOTP protocol messages, providing for:

   -- Authentication of IOTP transactions
   -- Provide a means by which an IOTP message may be made "tamper-
      proof", or detection of tampering is made evident
   -- Describe a set of available digest and signature algorithms at
      least one of which is mandatory to implement for interoperability
   -- Easily integrate within the IOTP 1.0 Specification
   -- Provide lightweight signatures with minimal redundancy
   -- Allow signed portions of IOTP message to be "forwarded" to another
      trading roles with different signature algorithms than the
      original recipient

3. Signature Basics

3.1 Signature Element

   This specification consists primarily of the definition of an XML
   element known as the Signature element. This element consists of two
   sub-elements. The first one is a set of authenticated attributes,
   known as the signature Manifest, which comprises such things as a



Davidson & Kawatsura         Informational                      [Page 3]

RFC 2802              Digital Signatures for IOTP             April 2000


   unique reference to the resources being authenticated and an
   indication of the keying material and algorithms being used. The
   second sub-element consists of the digital signature value.

   <Signature>
           <Manifest>
                   (resource information block)
                   (originator information block)
                   (recipient information block)
                   (other attributes)
                   (signature algorithms information block)
           </Manifest>
           <Value encoding 'encoding scheme'>
                   (encoded signature value)
           <Value>
   </Signature>

   The digital signature is not computed directly from the pieces of
   information to be authenticated. Instead, the digital signature is
   computed from a set of authenticated attributes (the Manifest), which
   include references to, and a digests of, those pieces of information.

   The authentication is therefore "indirect".

3.2 Digest Element

   The Digest element consists of a unique and unambiguous reference to
   the XML resources being authenticated. It is constructed of a locator
   and the digest value data itself. The Digest algorithm is referred to
   indirectly via a DigestAlgorithmRef, so that Digest algorithms may be
   shared by multiple resources.

   <Digest DigestAlgorithmRef='D.1'>
       <Locator href='resource locator'/>
       <Value>
            (Digest value)
       </Value>
   </Digest>

   The resource locator is implemented as a simple XML Link [XLink].
   This not only provides a unique addressing scheme for internal and
   external resources, but also facilitates authentication of composite
   documents.








Davidson & Kawatsura         Informational                      [Page 4]

RFC 2802              Digital Signatures for IOTP             April 2000


3.3 Originator and Recipient Information Elements

   The purpose of the Originator and Recipient information elements is
   to provide identification and keying material for these respective
   parties.

   <OriginatorInfo>
       (identification information block)
       (keying material information block)
   </OriginatorInfo>

   <RecipientInfo>
       (identification information block)
       (keying material information block)
   </RecipientInfo>

   The actual content of these two elements depends on the
   authentication scheme being used and the existence or non-existence
   of a prior relationship between the parties. In some circumstances,
   it may be quite difficult to distinguish between identification and
   keying material information. A unique reference to a digital
   certificate provides for both. This may also stand true for an
   account number when a prior relationship exists between the parties.

   The Originator information element is mandatory. Depending on the
   existence or non-existence of a prior relationship with the
   recipient, this block either refers to a public credential such as a
   digital certificate or displays a unique identifier known by the
   recipient.

   The Recipient information element may be used when a document
   contains multiple signature information blocks, each being intended
   for a particular recipient.  A unique reference in the Recipient
   information block helps the recipients identify their respective
   Signature information block.

   The Recipient information element may also be used when determination
   of the authentication key consists of a combination of keying
   material provided by both parties. This would be the case, for
   example, when establishing a key by means of Diffie Hellman
   [Schneier] Key Exchange algorithm.

3.4 Algorithm Element

   The Algorithm element is a generalized place to put any type of
   algorithm used within the signed IOTP message. The Algorithm may be a
   Signature algorithm or a Digest algorithm.  Each algorithm contains
   parameters specific to the algorithm used.



Davidson & Kawatsura         Informational                      [Page 5]

RFC 2802              Digital Signatures for IOTP             April 2000


      <Algorithm type='digest' ID='12'>
          (algorithm information block)
      </Algorithm>

   Algorithms are required to contain an ID which allows for indirect
   reference to them from other places in the XML signature.

4. Detailed Signature Syntax

4.1 Uniform Resource Names

   To prevent potential name conflicts in the definition of the numerous
   type qualifiers considered herein, this specification uses Uniform
   Resource Names  [RFC 2141].

4.2 IotpSignatures

   The IotpSignatures element is the top-level element in an IOTP
   signature block. It consists of a collection of Signature elements,
   and an optional set of Certificates.

   <!ELEMENT IotpSignatures (Signature+, Certificate*) >
   <!ATTLIST IotpSignatures
           ID             ID            #IMPLIED >

   Content Description

   Signature: A collection of Signature elements.

   Certificate: Zero or more certificates used for signing

   Attributes Description

   ID: Element identifier that may be used to reference the entire
   Signature element from a Resource element when implementing
   endorsement.

4.3 Signature Component

4.3.1 Signature

   The Signature element constitutes the majority of this specification.
   It is comprised of two sub-elements. The first one is a set of
   attributes, known as the Manifest, which actually constitutes the
   authenticated part of the document.  The second sub-element consists
   of the signature value or values.





Davidson & Kawatsura         Informational                      [Page 6]

RFC 2802              Digital Signatures for IOTP             April 2000


   The Value element contained within the Signature element is the
   encoded form of the signature of the Manifest element, and thus
   provides the verification of the Manifest.

   The process for generating the signed value is a multi-step process,
   involving a canonicalization algorithm, a digest algorithm, and a
   signature algorithm.

   First, the Manifest is canonicalized with an algorithm specified
   within the Algorithm element of the Manifest. The canonicalized form
   removes any inconsistencies in white space introduced by XML parsing
   engines.

   This canonicalized form is then converted into a digest form which
   uniquely identifies the canonicalized document. Any slight
   modification in the original document will result in a very different
   digest value.

   Finally, the digest is then signed using a public/symmetric key
   algorithm which digitally stamps the digest (with the certificate of
   the signer if available). The final signed digest is the value which
   is stored within the Signature's Value element.

   <!ELEMENT Signature (Manifest, Value+) >
   <!ATTLIST Signature
           ID              ID            #IMPLIED >

   Content Description

   Manifest: A set of attributes that actually constitutes the
   authenticated part of the document.

   Value:  One or more encodings of signature values. Multiple values
   allow for a multiple algorithms to be supported within a single
   signature component.

   Attributes Description

   ID: Element identifier that may be used to reference the Signature
   element from a Resource element when implementing endorsement.

4.3.2 Manifest

   The Manifest element consists of a collection of attributes that
   specify such things as references to the resources being
   authenticated and an indication of the keying material and algorithms
   to be used.




Davidson & Kawatsura         Informational                      [Page 7]

RFC 2802              Digital Signatures for IOTP             April 2000


   <!ELEMENT Manifest
           (       Algorithm+,
                   Digest+,
                   Attribute*,
                   OriginatorInfo,
                   RecipientInfo+,
           )
   <!ATTLIST Manifest
           LocatorHRefBase          CDATA        #IMPLIED
   >

   Content Description

   Algorithm: A list of algorithms used for signing, digest computation,
   and canonicalization.

   Digest: A list of digests of resources to be authentication and
   signed.

   Attribute: Optional element that consists of a collection of
   complementary attributes to be authenticated.

   OriginatorInfo: Element that provides identification and keying
   material information related to the originator.

   RecipientInfo: Optional element that provides identification and
   keying material information related to the recipient.

   Attributes Description

   LocatorHrefBase: The LocatorHrefBase provides a similar construct to
   the HTML HREFBASE attribute and implicitly sets all relative URL
   references within the Manifest to be relative to the HrefBase. For
   example, the IOTP Manifest may contain:

   <Manifest LocatorHrefBase='iotp:<globally-unique-tid>'>

   And subsequent Locators may be:

   <Locator href='C.9'>

   An implementation should concatenate the two locator references with
   "#" to create the entire URL. See definition of the Locator attribute
   on the Digest element for more detail.







Davidson & Kawatsura         Informational                      [Page 8]

RFC 2802              Digital Signatures for IOTP             April 2000


4.3.3 Algorithm

   This specification uses an Algorithm data type which indicates many
   different types of algoirithms. The Algorithm element allows for
   specification of sub-algorithms as parameters of the primary
   algorithm. This is performed via a parameter within the algorithm
   that provides a reference to another Algorithm. An example of this is
   shown in the Parameter section.

   <!ELEMENT Algorithm (Parameter*) >
   <!ATTLIST Algorithm
           ID             ID                #REQUIRED
           type     (digest|signature)      #IMPLIED
           name           NMTOKEN           #REQUIRED >

   Content Description

   Parameter: The contents of an Algorithm element consists of an
   optional collection of Parameter elements which are specified on a
   per algorithm basis.

   Attributes Description

   ID: The ID of the algorithm is used by the Digest and RecipientInfo
   to refer to the signing or digest algorithm used.

   type: The type of algorithm, either a digest or signature. This is
   implied by the element to which the algorithm is referred. That is,
   if the DigestAlgorithmRef refers to an algorithm, it is implicit by
   reference that the targeted algorithm is a digest.

   name:  The type of the algorithm expressed as a Uniform Resource
   Name.

4.3.4 Digest

   The Digest element consists of the fingerprint of a given resource.
   This element is constructed of two sub-elements. This first one
   indicates the algorithm to be used for computation of the
   fingerprint. The second element consists of the fingerprint value.

   <!ELEMENT Digest (Locator, Value) >
   <!ATTLIST Digest
           DigestAlgorithmRef       IDREF    #REQUIRED
   >






Davidson & Kawatsura         Informational                      [Page 9]

RFC 2802              Digital Signatures for IOTP             April 2000


   Content Description

   Locator: Contains a "HREF" or URL Locator for the resources to be
   fingerprinted. For use within IOTP a "scheme" with the value "iotp"
   may be used with the following structure:

     'iotp:<globally-unique-tid>#<id-value>'.

   This should be interpreted as referring to an element with an ID
   attribute that matches <id-value> in any IOTP Message that has a
   TransRefBlk Block with an IotpTransId that matches <globally-unique-
   tid>.

   If the LocatorHrefBase attribute is set on the Manifest element of
   which this Digest element is a child, then concatenate the value of
   the LocatorHrefBase attribute with the value of the Locator attribute
   before identifying the element that is being referred to.

   If the LocatorHrefBase attribute is omitted, <globally-unique-tid>
   should be interpreted as the current IotpTransId, which is included
   in the IOTP message which contains the Manifest component.

   Value: Encoding of the fingerprint value.

   Attributes Description

   DigestAlgorithmRef: ID Reference of algorithm used for computation of
   the digest.

4.3.5 Attribute

   The Attribute element consists of a complementary piece of
   information, which shall be included in the authenticated part of the
   document. This element has been defined primarily for enabling some
   level of customization in the signature element. This is the area
   where a specific IOTP implementation may include custom attributes
   which must be authenticated directly. An Attribute element consists
   of a value, a type, and a criticality.

   At this time, no IOTP specific attributes are specified.

   <!ELEMENT Attribute ANY >
   <!ATTLIST Attribute
           type               NMTOKEN           #REQUIRED
           critical        ( true | false )     #REQUIRED
   >





Davidson & Kawatsura         Informational                     [Page 10]

RFC 2802              Digital Signatures for IOTP             April 2000


   Content Description

   ANY: The actual value of an attribute depends solely upon its type.

   Attributes Description

   type:  Type of the attribute.

   critical: Boolean value that indicates if the attribute is critical
   (true) or not (false). A recipient shall reject a signature that
   contains a critical attribute that he does not recognize. However, an
   unrecognized non-critical attribute may be ignored.

4.3.6 OriginatorInfo

   The OriginatorInfo element is used for providing identification and
   keying material information for the originator.

   <!ELEMENT OriginatorInfo ANY >
   <!ATTLIST OriginatorInfo
           OriginatorRef       NMTOKEN      #IMPLIED
   >

   Content Description

   ANY:  Identification and keying material information may consist of
   ANY construct.  Such a definition allows the adoption of
   application-specific schemes.

   Attributes Description

   OriginatorRef: A reference to the IOTP Org ID of the originating
   signer.

4.3.7 RecipientInfo

   The RecipientInfo element is used for providing identification and
   keying material information for the recipient. This element is used
   either for enabling recognition of a Signature element by a given
   recipient or when determination of the authentication key consists of
   the combination of keying material provided by both the recipient and
   the originator.

   The RecipientInfo attributes provide a centralized location where
   signatures, algorithms, and certificates intended for a particular
   recipient are specified.





Davidson & Kawatsura         Informational                     [Page 11]

RFC 2802              Digital Signatures for IOTP             April 2000


   The signature certificate reference ID MUST point to a certificate
   object.

   <!ELEMENT RecipientInfo ANY >
   <!ATTLIST RecipientInfo
           SignatureAlgorithmRef   IDREF        #REQUIRED
           SignatureValueRef       IDREF        #IMPLIED
           SignatureCertRef        IDREF        #IMPLIED
           RecipientRefs           NMTOKENS     #IMPLIED
   >

   Content Description

   ANY:  Identification and keying material information may consist of
   ANY construct.

   Attributes Description

   SignatureAlgorithmRef: A reference to the signature algorithm used to
   sign the SignatureValueRef intended for this recipient. The signature
   algorithm reference ID MUST point to a signature algorithm within the
   Manifest.

   SignatureValueRef: A reference to the signature value for this
   recipient. The signature value reference ID MUST point to a value
   structure directly included within a Manifest. This reference can be
   omitted if the application can specify the digest value.

   SignatureCertRef: A reference to the certificate used to sign the
   Value pointed to by the SignatureValueRef. This reference can be
   omitted if the application can identify the certificate.

   RecipientRefs: A list of references to the IOTP Org ID of the
   recipients this signature is intended for.

4.3.8 KeyIdentifier

   The key identifier element can identify the shared public/symmetric
   key identification between parties that benefit from a prior
   relationship. This element can be included in the ReceipientInfo
   Element.

   <!ELEMENT KeyIdentifier EMPTY>
   <!ATTLIST KeyIdentifier
     value             CDATA        #REQUIRED
   >





Davidson & Kawatsura         Informational                     [Page 12]

RFC 2802              Digital Signatures for IOTP             April 2000


4.3.9 Parameter

   A Parameter element provides the value of a particular algorithm
   parameter, whose name and format have been specified for the
   algorithm considered.

   <!ELEMENT Parameter ANY >
   <!ATTLIST Parameter
           type       CDATA       #REQUIRED
   >

   For IOTP 1.0, the following parameter type is standardized:
   "AlgorithmRef".

   An AlgorithmRef contains an ID of a "sub-Algorithm" used when
   computing a sequence of algorithms. For example, a signature
   algorithm actually signs a digest algorithm. To specify a chain of
   algorithms used to compute a signature, AlgorithmRef parameter types
   are used in the following manner:

<Algorithm ID='A1' type='digest' name='urn:ibm-com:dom-hash'>
        <Parameter type='AlgorithmRef'>A2</Parameter>
</Algorithm>
<Algorithm ID='A2' type='digest' name='urn:nist-gov:sha1'>
</Algorithm>
<Algorithm ID='A3' type='signature' name='urn:rsasdi-com:rsa-encryption'>
        <Parameter type='AlgorithmRef'>A1</Parameter>
</Algorithm>

   Content Description

   ANY:  The contents of a Parameter element consists of ANY valid
   construct, which is specified on a per algorithm per parameter basis.

   Attributes Description

   type:  The type of the parameter expressed as a free form string,
   whose value is specified on a per algorithm basis.

4.4 Certificate Component

4.4.1 Certificate

   The Certificate element may be used for either providing the value of
   a digital certificate or specifying a location from where it may be
   retrieved.





Davidson & Kawatsura         Informational                     [Page 13]

RFC 2802              Digital Signatures for IOTP             April 2000


   <!ELEMENT Certificate
   (       IssuerAndSerialNumber,
           ( Value | Locator ) )
   >
   <!ATTLIST Certificate
           ID           ID           #IMPLIED
           type         NMTOKEN      #REQUIRED >

   Content Description

   IssuerAndSerialNumber:  Unique identifier of this certificate. This
   element has been made mandatory is order to prevent unnecessary
   decoding during validation of a certificate chain. This feature also
   helps certificates caching, especially when the value is not directly
   provided.

   Value: Encoding of the certificate value. The actual value to be
   encoded depends upon the type of the certificate.

   Locator: XML link element that could be used for retrieving a copy of
   the digital certificate. The actual value being returned by means of
   this locator depends upon the security protocol being used.

   Attributes Description

   ID: Element identifier that may be used to reference the Certificate
   element from a RecipientInfo element.

   type: Type of the digital certificate. This attribute is specified as
   a Universal Resource Name. Support for the X.509 version 3
   certificate [X.509] is mandatory in this specification if the
   Certificate element is used.  The URN for such certificates is
   "urn:X500:X509v3".

4.4.2 IssuerAndSerialNumber

   The IssuerAndSerialNumber element identifies a certificate, and
   thereby an entity and a public key, by the name of the certificate
   issuer and an issuer-specific certificate identification.

   <!ELEMENT IssuerAndSerialNumber EMPTY >
   <!ATTLIST IssuerAndSerialNumber
           issuer        CDATA         #REQUIRED
           number        CDATA         #REQUIRED >







Davidson & Kawatsura         Informational                     [Page 14]

RFC 2802              Digital Signatures for IOTP             April 2000


   Attributes Description

   issuer: Name of the issuing certification authority.  See [RFC 2253]
   for RECOMMENDED syntax.

   number: Issuer-specific certificate identification.

4.5 Common Components

4.5.1 Value

   A value contains the "raw" data of a signature or digest algorithm,
   usually in a base-64 encoded form. See [RFC 2045] for algorithm used
   to base-64 encode data.

   <!ELEMENT Value ( #PCDATA ) >
   <!ATTLIST Value
           ID                 ID            #IMPLIED
           encoding      (base64|none)     'base64'
   >

   Content Description

   PCDATA:  Content value after adequate encoding.

   Attributes Description

   encoding:  This attribute specifies the decoding scheme to be
   employed for recovering the original byte stream from the content of
   the element. This document recognizes the following two schemes:

   none: the content has not been subject to any particular encoding.
   This does not preclude however the use of native XML encoding such as
   CDATA section or XML escaping.

   base64: The content has been encoded by means of the base64 encoding
   scheme.

4.5.2 Locator

   The Locator element consists of simple XML link [XLink].  This
   element allows unambiguous reference to a resource or fragment of a
   resource.

   <!ELEMENT Locator EMPTY>
   <!ATTLIST Locator
           xml:link         CDATA        #FIXED         'simple'
           href             CDATA        #REQUIRED >



Davidson & Kawatsura         Informational                     [Page 15]

RFC 2802              Digital Signatures for IOTP             April 2000


   Attributes Description

   xml:link: Required XML link attribute that specifies the nature of
   the link (simple in this case).

   href: Locator value that may contains either a URI [RFC 2396], a
   fragment identifier, or both.

5. Supported Algorithms

   The IOTP specification 1.0 requires the implementation of the DSA,
   DOM-HASH, SHA1, HMAC algorithms. Implementation of RSA is also
   recommended.

5.1 Digest Algorithms

   This specification contemplates two types of digest algorithms, both
   of which provide a digest string as a result:

   Surface string digest algorithms

   These algorithms do not have any particular knowledge about the
   content being digested and operate on the raw content value. Any
   changes in the surface string of a given content affect directly the
   value of the digest being produced.

   Canonical digest algorithms

   These algorithms have been tailored for a particular content type and
   produce a digest value that depends upon the core semantics of such
   content. Changes limited to the surface string of a given content do
   not affect the value of the digest being produced unless they affect
   the core semantic.

5.1.1 SHA1

   Surface string digest algorithm designed by NIST and NSA for use with
   the Digital Signature Standard. This algorithm produces a 160-bit
   hash value. This algorithm is documented in NIST FIPS Publication
   180-1 [SHA1].

   This algorithm does not require any parameter.

   The SHA1 URN used for this specification is "urn:nist-gov:sha1".







Davidson & Kawatsura         Informational                     [Page 16]

RFC 2802              Digital Signatures for IOTP             April 2000


5.1.2 DOM-HASH

   XML canonical digest algorithm proposed by IBM Tokyo Research
   Laboratory. This algorithm operates on the DOM representation of the
   document and provides an unambiguous means for recursive computation
   of the hash value of the nodes that constitute the DOM tree [RFC
   2803]. This algorithm has many applications such as computation of
   digital signature and synchronization of DOM trees. However, because
   the hash value of an element is computed from the hash values of the
   inner elements, this algorithm is better adapted to small documents
   that do not require one-pass processing.

   As of today, this algorithm is limited to the contents of an XML
   document and, therefore, does not provide for authentication of the
   internal or external subset of the DTD.

   The DOM-HASH algorithm requires a single parameter, which shall
   include a surface string digest algorithm such as SHA1.

   The DOM-HASH URN used for this specification is "urn:ibm-com:dom-
   hash".

   The DOM-HASH uses a surface-string digest algorithm for computation
   of a fingerprint. The SHA1 is recommended in this specification.

   Example
   <Algorithm name='urn:fips:sha1' type='digest' ID='P.3'>
   </Algorithm>

   <Algorithm name='urn:ibm:dom-hash' type='digest' ID='P.5'>
     <Parameter type='AlgorithmRef'>P.3</Parameter>
   </Algorithm>

5.2 Signature Algorithms

   This specification uses the terminology of 'digital signature' for
   qualifying indifferently digital signature and message authentication
   codes.  Thus, the signature algorithms contemplated herein include
   public key digital signature algorithms such as ECDSA and message
   authentication codes such as HMAC [RFC 2104].

5.2.1 DSA

   Public-key signature algorithm proposed by NIST for use with the
   Digital Signature Standard. This standard is documented in NIST FIPS
   Publication 186 [DSS] and ANSI X9.30 [X9.30].





Davidson & Kawatsura         Informational                     [Page 17]

RFC 2802              Digital Signatures for IOTP             April 2000


   The DSA algorithm requires a single parameter, which includes the
   canonical digest algorithm to be used for computing the fingerprint
   of the signature Manifest.

   The DSA URN used in this specification is "urn:nist-gov:dsa".

   The DSA uses a canonical or surface-string digest algorithm for
   computation of the Manifest fingerprint. The DOM-HASH is recommended
   in this specification.

   Signature Value Encoding:

   The output of this algorithm consists of a pair of integers usually
   referred by the pair (r, s). The signature value shall consist of the
   concatenation of two octet-streams that respectively result from the
   octet-encoding of the values r and s. Integer to octet-stream
   conversion shall be done according to PKCS#1 [RFC 2437] specification
   with a k parameter equals to 20.

   Example
   <Algorithm name='urn:nist-gov:dsa' type='signature' ID='P.3'>
     <Parameter type='AlgorithmRef'>P.4</Parameter>
   </Algorithm>
   <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
     <Parameter type='AlgorithmRef'>P.5</Parameter>
   </Algorithm>
   <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
   </Algorithm>

5.2.2 HMAC

   Message Authentication Code proposed by H. Krawczyk et al., and
   documented in [RFC 2104].

   This specification adopts a scheme that differs a bit from the common
   usage of this algorithm -- computation of the MAC is performed on the
   hash of the contents being authenticated instead of the actual
   contents. Thence, the actual signature value output by the algorithm
   might be depicted as follows:

     SignatureValue = HMAC( SecretKey, H(Manifest))

   This specification also considered HMAC output truncation such as
   proposed by Preneel and van Oorschot. In their paper [PV] these two
   researchers have shown some analytical advantages of truncating the
   output of hash-based MAC functions. Such output truncation is also
   considered in the RFC document.




Davidson & Kawatsura         Informational                     [Page 18]

RFC 2802              Digital Signatures for IOTP             April 2000


   HMAC requires three parameters. The first one consists of a canonical
   digest algorithm. The second one consists of a hash function. The
   last one is optional and specifies the length in bit of the truncated
   output. If this last parameter is absent, no truncation shall occur.

   The HMAC URN used in this specification is "urn:ietf-org:hmac".

   Canonical digest algorithm: Canonical or surface-string digest
   algorithm is to be used for computation of the Manifest fingerprint.
   The type of this parameter is set to "AlgorithmRef".  The recommended
   value of this Parameter should be the ID reference for the Algorithm
   element DOM-HASH.

   Hash-function: Hash function is to be used to compute the MAC value
   from the secret key and the fingerprint of the signature Manifest.
   The type of this parameter is set to "HashAlgorithmRef" and the value
   of this parameter should be set to the ID reference for the Algorithm
   element of SHA1.

   Output-length: Length in bits of the truncated MAC value. The type of
   this parameter is set to "KeyLength" and the value of this parameter
   is set the length in bits of the truncated MAC value.

   Signature Value Encoding:

   The output of this algorithm can be assumed as a large integer value.
   The signature value shall consist of the octet-encoded value of this
   integer. Integer to octet-stream conversion shall be done according
   to PKCS#1 [RFC 2437] specification with a k parameter equals to
   ((Hlen +7) mod8), Mlen being the length in bits of the MAC value.

   Example
   <Algorithm name='urn:ietf-org:hmac' type='signature' ID='P.3'>
     <Parameter type='AlgorithmRef'>P.4</Parameter>
     <Parameter type='HashAlgorithmRef'>P.5</Parameter>
     <Parameter type='KeyLength'>128</Parameter>
   </Algorithm>
   <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
     <Parameter type='AlgorithmRef'>P.5</Parameter>
   </Algorithm>
   <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
   </Algorithm>









Davidson & Kawatsura         Informational                     [Page 19]

RFC 2802              Digital Signatures for IOTP             April 2000


5.2.3 RSA

   Public-key signature algorithm proposed by RSA Laboratories and
   documented in PKCS#1 [RFC 2437].

   This specification adopts the RSA encryption algorithm with padding
   block type 01. For computing the signature value, the signer shall
   first digest the signature Manifest and then encrypt the resulting
   digest with his private key.

   This signature algorithm requires a single parameter, which consists
   of the canonical digest algorithm to be used for computing the
   fingerprint of the signature Manifest.

   Specifications

   The RSA URN used in this specification is "urn:rsasdi-com:rsa-
   encription".

   The RSA uses a canonical or surface-string digest algorithm for
   computation of the Manifest fingerprint. The DOM-HASH is recommended
   in this specification.

   Signature Value Encoding:

   The output of this algorithm consists of single octet-stream. No
   further encoding is required.

   Example
   <Algorithm name='urn:rsasdi-com:rsa-encription'
                                       type='signature' ID='P.3'>
     <Parameter type='AlgorithmRef'>P.4</Parameter>
   </Algorithm>
   <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
     <Parameter type='AlgorithmRef'>P.5</Parameter>
   </Algorithm>
   <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
   </Algorithm>

5.2.4 ECDSA

   Public-key signature algorithm proposed independently by Neil Koblitz
   and Victor Miller. This algorithm is being proposed as an ANSI
   standard and is documented in ANSI X9.62 standard proposal [X9.62]
   and IEEE/P1363 standard draft proposal [IEEE P1363].






Davidson & Kawatsura         Informational                     [Page 20]

RFC 2802              Digital Signatures for IOTP             April 2000


   The ECDSA algorithm requires a single parameter, which consists of
   the canonical digest algorithm to be used for computing the
   fingerprint of the signature Manifest.

   Specifications

   The ECDSA URN used in this specification is "urn:ansi-org:ecdsa".

   The ECDSA uses a canonical or surface-string digest algorithm for
   computation of the Manifest fingerprint. The DOM-HASH [RFC 2803] is
   recommended in this specification.

   Signature Value Encoding:

   The output of this algorithm consists of a pair of integers usually
   referred by the pair (r, s). The signature value shall consist of the
   concatenation of two octet-streams that respectively result from the
   octet-encoding of the values r and s. Integer to octet-stream
   conversion shall be done according to PKCS#1 [RFC 2437] specification
   with a k parameter equals to 20.

   Example
   <Algorithm name='urn:ansi-org:ecdsa' type='signature' ID='P.3'>
     <Parameter type='AlgorithmRef'>P.4</Parameter>
   </Algorithm>
   <Algorithm name='urn:ibm-com:dom-hash' type='digest' ID='P.4'>
     <Parameter type='AlgorithmRef'>P.5</Parameter>
   </Algorithm>
   <Algorithm name='urn:nist-gov:sha1' type='digest' ID='P.5'>
   </Algorithm>

6. Examples

   The following is an example signed IOTP message:

   <IotpMessage>
      <TransRefBlk ID='M.1'>
          <TransId
              ID='M.2'
              version='1.0'
              IotpTransID='19990809215923@www.iotp.org'
              IotpTransType='BaselinePurchase'
              TransTimeStamp='1999-08-09T12:58:40.000Z+9'>
          </TransId>
          <MsgId xml:lang='en' SoftwareID='Iotp wallet version 1.0'>
          </MsgId>
      </TransRefBlk>
      <IotpSignatures>



Davidson & Kawatsura         Informational                     [Page 21]

RFC 2802              Digital Signatures for IOTP             April 2000


          <Signature>
              <Manifest>
                  <Algorithm name='urn:nist-gov:sha1'
                                              type='digest' ID='P.3'>
                  </Algorithm>
                  <Algorithm name='urn:nist-gov:dsa'
                                              type='signature' ID='P.4'>
                      <Parameter type='AlgorithmRef'>P.5</Parameter>
                  </Algorithm>
                  <Algorithm name='urn:ibm-com:dom-hash'
                                              type='digest' ID='P.5'>
                      <Parameter type='AlgorithmRef'>P.3</Parameter>
                  </Algorithm>
                  <Digest DigestAlgorithmRef='P.6'>
                      <Locator href='P.1'/>
                      <Value>
                       xsqsfasDys2h44u4ehJDe54he5j4dJYTJ
                      </Value>
                  </Digest>
                  <OriginatorInfo
                      <IssuerAndSerialNumber
                       issuer='o=Iotp Ltd., c=US'
                       number='12345678987654'/>
                  </OriginatorInfo>
                  <RecipientInfo
                      SignatureAlgorithmRef='P.4'
                  </RecipientInfo>
              </Manifest>
              <Value>
                   9dj28fjakA9sked0Ks01k2d7a0kgmf9dk19lf63kkDSs0
              </Value>
          </Signature>
          <Certificate type='urn:X500:X509v3'>
              <IssuerAndSerialNumber
                   issuer='o=GlobeSet Inc., c=US'
                   number='123456789102356'/>
              <Value>
               xsqsfasDys2h44u4ehJDe54he5j4dJYTJ=
              </Value>
         </Certificate>
      </IotpSignatures>
      <PayExchBlk ID='P.1'>
          <PaySchemeData
              ID='P.2'
              PaymentRef='M.5'
              ContentSoftwareId='abcdefg'>
                  <PackagedContent Name='FirstPiece'>
                       snroasdfnas934k



Davidson & Kawatsura         Informational                     [Page 22]

RFC 2802              Digital Signatures for IOTP             April 2000


                  </PackagedContent>
         </PaySchemeData>
      </PayExchBlk>
   </IotpMessage>

7. Signature DTD

   <!--
   ******************************************************
   * IOTP SIGNATURES BLOCK DEFINITION                   *
   ******************************************************
   -->

   <!ELEMENT IotpSignatures (Signature+ ,Certificate*) >
   <!ATTLIST IotpSignatures
           ID        ID        #IMPLIED
   >

   <!--
   ******************************************************
   * IOTP SIGNATURE COMPONENT DEFINITION                *
   ******************************************************
   -->

   <!ELEMENT Signature (Manifest, Value+) >
   <!ATTLIST Signature
           ID         ID        #IMPLIED
   >

   <!ELEMENT Manifest
           (       Algorithm+,
                   Digest+,
                   Attribute*,
                   OriginatorInfo,
                   RecipientInfo+
           )
   >

   <!ATTLIST Manifest
           LocatorHRefBase       CDATA             #IMPLIED
   >

   <!ELEMENT Algorithm (Parameter*) >
   <!ATTLIST Algorithm
           ID                     ID                #REQUIRED
           type            (digest|signature)      #IMPLIED
           name                  NMTOKEN           #REQUIRED
   >



Davidson & Kawatsura         Informational                     [Page 23]

RFC 2802              Digital Signatures for IOTP             April 2000


   <!ELEMENT Digest (Locator, Value) >
   <!ATTLIST Digest
           DigestAlgorithmRef    IDREF             #REQUIRED
   >

   <!ELEMENT Attribute ANY >
   <!ATTLIST Attribute
           type                   NMTOKEN           #REQUIRED
           critical            ( true | false )     #REQUIRED
   >

   <!ELEMENT OriginatorInfo ANY >
   <!ATTLIST OriginatorInfo
           OriginatorRef           NMTOKEN          #IMPLIED
   >

   <!ELEMENT RecipientInfo ANY >
   <!ATTLIST RecipientInfo
           SignatureAlgorithmRef   IDREF            #REQUIRED
           SignatureValueRef       IDREF            #IMPLIED
           SignatureCertRef        IDREF            #IMPLIED
           RecipientRefs           NMTOKENS         #IMPLIED
   >

   <!ELEMENT KeyIdentifier EMPTY>
   <!ATTLIST KeyIdentifier
           value                    CDATA           #REQUIRED
   >

   <!ELEMENT Parameter ANY >
   <!ATTLIST Parameter
           type                     CDATA           #REQUIRED
   >

   <!--
   ******************************************************
   * IOTP CERTIFICATE COMPONENT DEFINITION              *
   ******************************************************
   -->

   <!ELEMENT Certificate
     (  IssuerAndSerialNumber,  ( Value | Locator ) )
   >

   <!ATTLIST Certificate
           ID                        ID                #IMPLIED
           type                      NMTOKEN           #REQUIRED
   >



Davidson & Kawatsura         Informational                     [Page 24]

RFC 2802              Digital Signatures for IOTP             April 2000


   <!ELEMENT IssuerAndSerialNumber EMPTY >
   <!ATTLIST IssuerAndSerialNumber
           issuer                     CDATA            #REQUIRED
           number                     CDATA            #REQUIRED
   >

   <!--
   ******************************************************
   * IOTP SHARED COMPONENT DEFINITION                   *
   ******************************************************
   -->
   <!ELEMENT Value ( #PCDATA ) >
   <!ATTLIST Value
           ID               ID           #IMPLIED
           encoding    (base64|none      'base64'
   >

   <!ELEMENT Locator EMPTY>
   <!ATTLIST Locator
           xml:link        CDATA         #FIXED        'simple'
           href            CDATA         #REQUIRED
   >

8. Security Considerations

   This entire document concerns the IOTP v1 protocol signature element
   which is used for authentication.  See the Security Considerations
   section of [RFC 2801] "Internet Open Trading Protocol - IOTP, Version
   1.0".






















Davidson & Kawatsura         Informational                     [Page 25]

RFC 2802              Digital Signatures for IOTP             April 2000


References

   [DSA]        Federal Information Processing Standards Publication
                FIPS PUB 186, "Digital Signature Standard(DSS)", 1994,
                <http://csrc.nist.gov>

   [IEEE P1363] IEEE P1363, "Standard Specifications for Public-Key
                Cryptography", Work in Progress, 1997,
                <http://stdsbbs.ieee.org/>

   [PV]         Preneel, B. and P. van Oorschot, "Building fast MACs
                from hash functions", Advances in Cryptology --
                CRYPTO'95 Proceedings, Lecture Notes in Computer
                Science, Springer-Verlag Vol.963, 1995, pp. 1-14.

   [RFC 1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC
                1321, April 1992.

   [RFC 2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bodies", RFC 2045, November 1996.

   [RFC 2046]   Freed N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part Two: Media Types", RFC 2046,
                November 1996.

   [RFC 2104]   Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
                Hashing for Message Authentication", RFC 2104, February
                1997.

   [RFC 2141]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC 2253]   Wahl, W., Kille, S. and T. Howes, "Lightweight Directory
                Access Protocol (v3): UTF-8 String Representation of
                Distinguished Names", RFC 2253, December 1997.

   [RFC 2396]   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
                Resource Identifiers (URI): Generic Syntax", RFC 2396,
                August 1998.

   [RFC 2437]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
                Specifications, Version 2.0", RFC 2437, October 1998.

   [RFC 2801]   Burdett, D., "Internet Open Trading Protocol - IOTP,
                Version 1.0", RFC 2801, April 2000.

   [RFC 2803]   Maruyama, H., Tamura, K. and N. Uramot, "Digest Values
                for DOM (DOMHASH)", RFC 2803, April 2000.



Davidson & Kawatsura         Informational                     [Page 26]

RFC 2802              Digital Signatures for IOTP             April 2000


   [Schneier]   Bruce Schneier, "Applied Cryptography: Protocols,
                Algorithms, and Source Code in C", 1996, John Wiley and
                Sons

   [SHA1]       NIST FIPS PUB 180-1, "Secure Hash Standard," National
                Institute of Standards and Technology, U.S. Department
                of Commerce, April 1995.

   [X.509]      ITU-T Recommendation X.509 (1997 E), "Information
                Technology - Open Systems Interconnection - The
                Directory:  Authentication Framework", June 1997.

   [X9.30]      ASC X9 Secretariat: American Bankers Association,
                "American National Standard for Financial Services -
                Public Key Cryptography Using Irreversible Algorithms
                for the Financial Services Industry - Part 1: The
                Digital Signature Algorithm(DSA)", 1995.

   [X9.62]      ASC X9 Secretariat: American Bankers
                Association,"American National Standard for Financial
                Services - Public Key Cryptography Using Irreversible
                Algorithms for the Financial Services Industry - The
                Elliptic Curve Digital Signature Algorithm (ECDSA)",
                Work in Progress, 1997.

   [XLink]      Eve Maler, Steve DeRose, "XML Linking Language (XLink)",
                <http://www.w3.org/TR/1998/WD-xlink-19980303>

   [XML]        Tim Bray, Jean Paoli, C. M. Sperber-McQueen, "Extensible
                Markup Language (XML) 1.0",
                <http://www.w3.org/TR/1998/REC-xml-19980210>




















Davidson & Kawatsura         Informational                     [Page 27]

RFC 2802              Digital Signatures for IOTP             April 2000


Authors' Addresses

   The authors of this document are:

   Kent M. Davidson
   Differential, Inc.
   440 Clyde Ave.
   Mountain View, CA 94043 USA

   EMail: kent@differential.com


   Yoshiaki Kawatsura
   Hitachi, Ltd.
   890-12 Kashimada Saiwai Kawasaki,
   Kanagawa 2128567 Japan

   EMail: kawatura@bisd.hitachi.co.jp

































Davidson & Kawatsura         Informational                     [Page 28]

RFC 2802              Digital Signatures for IOTP             April 2000


Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.



















Davidson & Kawatsura         Informational                     [Page 29]