summaryrefslogtreecommitdiff
path: root/doc/protocol/rfc3279.txt
blob: 04e7b075d45ea68336b9e996b653e014fb3419d1 (plain)
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






Network Working Group                                            W. Polk
Request for Comments: 3279                                          NIST
Obsoletes: 2528                                               R. Housley
Category: Standards Track                               RSA Laboratories
                                                              L. Bassham
                                                                    NIST
                                                              April 2002

                   Algorithms and Identifiers for the
                Internet X.509 Public Key Infrastructure
       Certificate and Certificate Revocation List (CRL) Profile

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This document specifies algorithm identifiers and ASN.1 encoding
   formats for digital signatures and subject public keys used in the
   Internet X.509 Public Key Infrastructure (PKI).  Digital signatures
   are used to sign certificates and certificate revocation list (CRLs).
   Certificates include the public key of the named subject.

Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . .   2
   2  Algorithm Support . . . . . . . . . . . . . . . . . . . .   3
   2.1  One-Way Hash Functions  . . . . . . . . . . . . . . . .   3
   2.1.1  MD2 One-Way Hash Functions  . . . . . . . . . . . . .   3
   2.1.2  MD5 One-Way Hash Functions  . . . . . . . . . . . . .   4
   2.1.3  SHA-1 One-Way Hash Functions  . . . . . . . . . . . .   4
   2.2  Signature Algorithms  . . . . . . . . . . . . . . . . .   4
   2.2.1  RSA Signature Algorithm . . . . . . . . . . . . . . .   5
   2.2.2  DSA Signature Algorithm . . . . . . . . . . . . . . .   6
   2.2.3  Elliptic Curve Digital Signature Algorithm  . . . . .   7
   2.3  Subject Public Key Algorithms . . . . . . . . . . . . .   7
   2.3.1  RSA Keys  . . . . . . . . . . . . . . . . . . . . . .   8
   2.3.2  DSA Signature Keys  . . . . . . . . . . . . . . . . .   9
   2.3.3  Diffie-Hellman Key Exchange Keys  . . . . . . . . . .  10



Polk, et al.                Standards Track                     [Page 1]

RFC 3279               Algorithms and Identifiers             April 2002


   2.3.4  KEA Public Keys . . . . . . . . . . . . . . . . . . .  11
   2.3.5  ECDSA and ECDH Public Keys  . . . . . . . . . . . . .  13
   3  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . . .  18
   4  References  . . . . . . . . . . . . . . . . . . . . . . .  24
   5  Security Considerations . . . . . . . . . . . . . . . . .  25
   6  Intellectual Property Rights  . . . . . . . . . . . . . .  26
   7  Author Addresses  . . . . . . . . . . . . . . . . . . . .  26
   8  Full Copyright Statement  . . . . . . . . . . . . . . . .  27

1  Introduction

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

   This document specifies algorithm identifiers and ASN.1 [X.660]
   encoding formats for digital signatures and subject public keys used
   in the Internet X.509 Public Key Infrastructure (PKI).  This
   specification supplements [RFC 3280], "Internet X.509 Public Key
   Infrastructure:  Certificate and Certificate Revocation List (CRL)
   Profile."  Implementations of this specification MUST also conform to
   RFC 3280.

   This specification defines the contents of the signatureAlgorithm,
   signatureValue, signature, and subjectPublicKeyInfo fields within
   Internet X.509 certificates and CRLs.

   This document identifies one-way hash functions for use in the
   generation of digital signatures.  These algorithms are used in
   conjunction with digital signature algorithms.

   This specification describes the encoding of digital signatures
   generated with the following cryptographic algorithms:

      * Rivest-Shamir-Adelman (RSA);
      * Digital Signature Algorithm (DSA); and
      * Elliptic Curve Digital Signature Algorithm (ECDSA).

   This document specifies the contents of the subjectPublicKeyInfo
   field in Internet X.509 certificates.  For each algorithm, the
   appropriate alternatives for the the keyUsage extension are provided.
   This specification describes encoding formats for public keys used
   with the following cryptographic algorithms:

      * Rivest-Shamir-Adelman (RSA);
      * Digital Signature Algorithm (DSA);
      * Diffie-Hellman (DH);
      * Key Encryption Algorithm (KEA);



Polk, et al.                Standards Track                     [Page 2]

RFC 3279               Algorithms and Identifiers             April 2002


      * Elliptic Curve Digital Signature Algorithm (ECDSA); and
      * Elliptic Curve Diffie-Hellman (ECDH).

2  Algorithm Support

   This section describes cryptographic algorithms which may be used
   with the Internet X.509 certificate and CRL profile [RFC 3280].  This
   section describes one-way hash functions and digital signature
   algorithms which may be used to sign certificates and CRLs, and
   identifies object identifiers (OIDs) for public keys contained in a
   certificate.

   Conforming CAs and applications MUST, at a minimum, support digital
   signatures and public keys for one of the specified algorithms.  When
   using any of the algorithms identified in this specification,
   conforming CAs and applications MUST support them as described.

2.1  One-way Hash Functions

   This section identifies one-way hash functions for use in the
   Internet X.509 PKI.  One-way hash functions are also called message
   digest algorithms.  SHA-1 is the preferred one-way hash function for
   the Internet X.509 PKI.  However, PEM uses MD2 for certificates [RFC
   1422] [RFC 1423] and MD5 is used in other legacy applications.  For
   these reasons, MD2 and MD5 are included in this profile.  The data
   that is hashed for certificate and CRL signing is fully described in
   [RFC 3280].

2.1.1  MD2 One-way Hash Function

   MD2 was developed by Ron Rivest for RSA Security.  RSA Security has
   recently placed the MD2 algorithm in the public domain.  Previously,
   RSA Data Security had granted license for use of MD2 for non-
   commercial Internet Privacy-Enhanced Mail (PEM).  MD2 may continue to
   be used with PEM certificates, but SHA-1 is preferred.  MD2 produces
   a 128-bit "hash" of the input.  MD2 is fully described in [RFC 1319].

   At the Selected Areas in Cryptography '95 conference in May 1995,
   Rogier and Chauvaud presented an attack on MD2 that can nearly find
   collisions [RC95].  Collisions occur when one can find two different
   messages that generate the same message digest.  A checksum operation
   in MD2 is the only remaining obstacle to the success of the attack.
   For this reason, the use of MD2 for new applications is discouraged.
   It is still reasonable to use MD2 to verify existing signatures, as
   the ability to find collisions in MD2 does not enable an attacker to
   find new messages having a previously computed hash value.





Polk, et al.                Standards Track                     [Page 3]

RFC 3279               Algorithms and Identifiers             April 2002


2.1.2  MD5 One-way Hash Function

   MD5 was developed by Ron Rivest for RSA Security.  RSA Security has
   placed the MD5 algorithm in the public domain.  MD5 produces a 128-
   bit "hash" of the input.  MD5 is fully described in [RFC 1321].

   Den Boer and Bosselaers [DB94] have found pseudo-collisions for MD5,
   but there are no other known cryptanalytic results.  The use of MD5
   for new applications is discouraged.  It is still reasonable to use
   MD5 to verify existing signatures.

2.1.3  SHA-1 One-way Hash Function

   SHA-1 was developed by the U.S. Government.  SHA-1 produces a 160-bit
   "hash" of the input.  SHA-1 is fully described in [FIPS 180-1].  RFC
   3174 [RFC 3174] also describes SHA-1, and it provides an
   implementation of the algorithm.

2.2  Signature Algorithms

   Certificates and CRLs conforming to [RFC 3280] may be signed with any
   public key signature algorithm.  The certificate or CRL indicates the
   algorithm through an algorithm identifier which appears in the
   signatureAlgorithm field within the Certificate or CertificateList.
   This algorithm identifier is an OID and has optionally associated
   parameters.  This section identifies algorithm identifiers and
   parameters that MUST be used in the signatureAlgorithm field in a
   Certificate or CertificateList.

   Signature algorithms are always used in conjunction with a one-way
   hash function.

   This section identifies OIDS for RSA, DSA, and ECDSA.  The contents
   of the parameters component for each algorithm vary; details are
   provided for each algorithm.

   The data to be signed (e.g., the one-way hash function output value)
   is formatted for the signature algorithm to be used.  Then, a private
   key operation (e.g., RSA encryption) is performed to generate the
   signature value.  This signature value is then ASN.1 encoded as a BIT
   STRING and included in the Certificate or CertificateList in the
   signature field.









Polk, et al.                Standards Track                     [Page 4]

RFC 3279               Algorithms and Identifiers             April 2002


2.2.1  RSA Signature Algorithm

   The RSA algorithm is named for its inventors: Rivest, Shamir, and
   Adleman.  This profile includes three signature algorithms based on
   the RSA asymmetric encryption algorithm.  The signature algorithms
   combine RSA with either the MD2, MD5, or the SHA-1 one-way hash
   functions.

   The signature algorithm with SHA-1 and the RSA encryption algorithm
   is implemented using the padding and encoding conventions described
   in PKCS #1 [RFC 2313].  The message digest is computed using the
   SHA-1 hash algorithm.

   The RSA signature algorithm, as specified in PKCS #1 [RFC 2313]
   includes a data encoding step.  In this step, the message digest and
   the OID for the one-way hash function used to compute the digest are
   combined.  When performing the data encoding step, the md2, md5, and
   id-sha1 OIDs MUST be used to specify the MD2, MD5, and SHA-1 one-way
   hash functions, respectively:

      md2  OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549)
           digestAlgorithm(2) 2 }

      md5  OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) US(840) rsadsi(113549)
           digestAlgorithm(2) 5 }

      id-sha1  OBJECT IDENTIFIER ::= {
           iso(1) identified-organization(3) oiw(14) secsig(3)
           algorithms(2) 26 }

   The signature algorithm with MD2 and the RSA encryption algorithm is
   defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
   ASN.1 OID used to identify this signature algorithm is:

      md2WithRSAEncryption OBJECT IDENTIFIER  ::=  {
          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-1(1) 2  }

   The signature algorithm with MD5 and the RSA encryption algorithm is
   defined in PKCS #1 [RFC 2313].  As defined in PKCS #1 [RFC 2313], the
   ASN.1 OID used to identify this signature algorithm is:

      md5WithRSAEncryption OBJECT IDENTIFIER  ::=  {
          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-1(1) 4  }




Polk, et al.                Standards Track                     [Page 5]

RFC 3279               Algorithms and Identifiers             April 2002


   The ASN.1 object identifier used to identify this signature algorithm
   is:

      sha-1WithRSAEncryption OBJECT IDENTIFIER  ::=  {
          iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
          pkcs-1(1) 5  }

   When any of these three OIDs appears within the ASN.1 type
   AlgorithmIdentifier, the parameters component of that type SHALL be
   the ASN.1 type NULL.

   The RSA signature generation process and the encoding of the result
   is described in detail in PKCS #1 [RFC 2313].

2.2.2  DSA Signature Algorithm

   The Digital Signature Algorithm (DSA) is defined in the Digital
   Signature Standard (DSS).  DSA was developed by the U.S. Government,
   and DSA is used in conjunction with the SHA-1 one-way hash function.
   DSA is fully described in [FIPS 186].  The ASN.1 OID used to identify
   this signature algorithm is:

      id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
           iso(1) member-body(2) us(840) x9-57 (10040)
           x9cm(4) 3 }

   When the id-dsa-with-sha1 algorithm identifier appears as the
   algorithm field in an AlgorithmIdentifier, the encoding SHALL omit
   the parameters field.  That is, the AlgorithmIdentifier SHALL be a
   SEQUENCE of one component: the OBJECT IDENTIFIER id-dsa-with-sha1.

   The DSA parameters in the subjectPublicKeyInfo field of the
   certificate of the issuer SHALL apply to the verification of the
   signature.

   When signing, the DSA algorithm generates two values.  These values
   are commonly referred to as r and s.  To easily transfer these two
   values as one signature, they SHALL be ASN.1 encoded using the
   following ASN.1 structure:

      Dss-Sig-Value  ::=  SEQUENCE  {
              r       INTEGER,
              s       INTEGER  }








Polk, et al.                Standards Track                     [Page 6]

RFC 3279               Algorithms and Identifiers             April 2002


2.2.3 ECDSA Signature Algorithm

   The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
   [X9.62].  The ASN.1 object identifiers used to identify ECDSA are
   defined in the following arc:

      ansi-X9-62  OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) us(840) 10045 }

      id-ecSigType OBJECT IDENTIFIER  ::=  {
           ansi-X9-62 signatures(4) }

   ECDSA is used in conjunction with the SHA-1 one-way hash function.
   The ASN.1 object identifier used to identify ECDSA with SHA-1 is:

      ecdsa-with-SHA1  OBJECT IDENTIFIER ::= {
           id-ecSigType 1 }

   When the ecdsa-with-SHA1 algorithm identifier appears as the
   algorithm field in an AlgorithmIdentifier, the encoding MUST omit the
   parameters field.  That is, the AlgorithmIdentifier SHALL be a
   SEQUENCE of one component: the OBJECT IDENTIFIER ecdsa-with-SHA1.

   The elliptic curve parameters in the subjectPublicKeyInfo field of
   the certificate of the issuer SHALL apply to the verification of the
   signature.

   When signing, the ECDSA algorithm generates two values.  These values
   are commonly referred to as r and s.  To easily transfer these two
   values as one signature, they MUST be ASN.1 encoded using the
   following ASN.1 structure:

      Ecdsa-Sig-Value  ::=  SEQUENCE  {
           r     INTEGER,
           s     INTEGER  }

2.3  Subject Public Key Algorithms

   Certificates conforming to [RFC 3280] may convey a public key for any
   public key algorithm.  The certificate indicates the algorithm
   through an algorithm identifier.  This algorithm identifier is an OID
   and optionally associated parameters.

   This section identifies preferred OIDs and parameters for the RSA,
   DSA, Diffie-Hellman, KEA, ECDSA, and ECDH algorithms.  Conforming CAs
   MUST use the identified OIDs when issuing certificates containing





Polk, et al.                Standards Track                     [Page 7]

RFC 3279               Algorithms and Identifiers             April 2002


   public keys for these algorithms.  Conforming applications supporting
   any of these algorithms MUST, at a minimum, recognize the OID
   identified in this section.

2.3.1  RSA Keys

   The OID rsaEncryption identifies RSA public keys.

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

      rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}

   The rsaEncryption OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier.  The parameters field MUST
   have ASN.1 type NULL for this algorithm identifier.

   The RSA public key MUST be encoded using the ASN.1 type RSAPublicKey:

      RSAPublicKey ::= SEQUENCE {
         modulus            INTEGER,    -- n
         publicExponent     INTEGER  }  -- e

   where modulus is the modulus n, and publicExponent is the public
   exponent e.  The DER encoded RSAPublicKey is the value of the BIT
   STRING subjectPublicKey.

   This OID is used in public key certificates for both RSA signature
   keys and RSA encryption keys.  The intended application for the key
   MAY be indicated in the key usage field (see [RFC 3280]).  The use of
   a single key for both signature and encryption purposes is not
   recommended, but is not forbidden.

   If the keyUsage extension is present in an end entity certificate
   which conveys an RSA public key, any combination of the following
   values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyEncipherment; and
      dataEncipherment.

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys an RSA public key, any combination of the
   following values MAY be present:

      digitalSignature;
      nonRepudiation;



Polk, et al.                Standards Track                     [Page 8]

RFC 3279               Algorithms and Identifiers             April 2002


      keyEncipherment;
      dataEncipherment;
      keyCertSign; and
      cRLSign.

   However, this specification RECOMMENDS that if keyCertSign or cRLSign
   is present, both keyEncipherment and dataEncipherment SHOULD NOT be
   present.

2.3.2  DSA Signature Keys

   The Digital Signature Algorithm (DSA) is defined in the Digital
   Signature Standard (DSS) [FIPS 186].  The DSA OID supported by this
   profile is:

      id-dsa OBJECT IDENTIFIER ::= {
           iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

   The id-dsa algorithm syntax includes optional domain parameters.
   These parameters are commonly referred to as p, q, and g.  When
   omitted, the parameters component MUST be omitted entirely.  That is,
   the AlgorithmIdentifier MUST be a SEQUENCE of one component: the
   OBJECT IDENTIFIER id-dsa.

   If the DSA domain parameters are present in the subjectPublicKeyInfo
   AlgorithmIdentifier, the parameters are included using the following
   ASN.1 structure:

      Dss-Parms  ::=  SEQUENCE  {
          p             INTEGER,
          q             INTEGER,
          g             INTEGER  }

   The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
   within a certificate where the parameters may be used.  If the DSA
   algorithm parameters are omitted from the subjectPublicKeyInfo
   AlgorithmIdentifier and the CA signed the subject certificate using
   DSA, then the certificate issuer's DSA parameters apply to the
   subject's DSA key.  If the DSA domain parameters are omitted from the
   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
   subject certificate using a signature algorithm other than DSA, then
   the subject's DSA domain parameters are distributed by other means.
   If the subjectPublicKeyInfo AlgorithmIdentifier field omits the
   parameters component, the CA signed the subject with a signature
   algorithm other than DSA, and the subject's DSA parameters are not
   available through other means, then clients MUST reject the
   certificate.




Polk, et al.                Standards Track                     [Page 9]

RFC 3279               Algorithms and Identifiers             April 2002


   The DSA public key MUST be ASN.1 DER encoded as an INTEGER; this
   encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

      DSAPublicKey ::= INTEGER -- public key, Y

   If the keyUsage extension is present in an end entity certificate
   which conveys a DSA public key, any combination of the following
   values MAY be present:

      digitalSignature;
      nonRepudiation;

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys a DSA public key, any combination of the
   following values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyCertSign; and
      cRLSign.

2.3.3  Diffie-Hellman Key Exchange Keys

   The Diffie-Hellman OID supported by this profile is defined in
   [X9.42].

      dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                us(840) ansi-x942(10046) number-type(2) 1 }

   The dhpublicnumber OID is intended to be used in the algorithm field
   of a value of type AlgorithmIdentifier.  The parameters field of that
   type, which has the algorithm-specific syntax ANY DEFINED BY
   algorithm, have the ASN.1 type DomainParameters for this algorithm.

      DomainParameters ::= SEQUENCE {
            p       INTEGER, -- odd prime, p=jq +1
            g       INTEGER, -- generator, g
            q       INTEGER, -- factor of p-1
            j       INTEGER OPTIONAL, -- subgroup factor
            validationParms  ValidationParms OPTIONAL }

      ValidationParms ::= SEQUENCE {
            seed             BIT STRING,
            pgenCounter      INTEGER }





Polk, et al.                Standards Track                    [Page 10]

RFC 3279               Algorithms and Identifiers             April 2002


   The fields of type DomainParameters have the following meanings:

      p identifies the prime p defining the Galois field;

      g specifies the generator of the multiplicative subgroup of order
      g;

      q specifies the prime factor of p-1;

      j optionally specifies the value that satisfies the equation
      p=jq+1 to support the optional verification of group parameters;

      seed optionally specifies the bit string parameter used as the
      seed for the domain parameter generation process; and

      pgenCounter optionally specifies the integer value output as part
      of the of the domain parameter prime generation process.

   If either of the domain parameter generation components (pgenCounter
   or seed) is provided, the other MUST be present as well.

   The Diffie-Hellman public key MUST be ASN.1 encoded as an INTEGER;
   this encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
   data element.

      DHPublicKey ::= INTEGER -- public key, y = g^x mod p

   If the keyUsage extension is present in a certificate which conveys a
   DH public key, the following values may be present:

      keyAgreement;
      encipherOnly; and
      decipherOnly.

   If present, the keyUsage extension MUST assert keyAgreement and MAY
   assert either encipherOnly and decipherOnly.  The keyUsage extension
   MUST NOT assert both encipherOnly and decipherOnly.

2.3.4 KEA Public Keys

   This section identifies the preferred OID and parameters for the
   inclusion of a KEA public key in a certificate.  The Key Exchange
   Algorithm (KEA) is a key agreement algorithm.  Two parties may
   generate a "pairwise key" if and only if they share the same KEA
   parameters.  The KEA parameters are not included in a certificate;
   instead a domain identifier is supplied in the parameters field.




Polk, et al.                Standards Track                    [Page 11]

RFC 3279               Algorithms and Identifiers             April 2002


   When the SubjectPublicKeyInfo field contains a KEA key, the algorithm
   identifier and parameters SHALL be as defined in [SDN.701r]:

      id-keyExchangeAlgorithm  OBJECT IDENTIFIER   ::=
             { 2 16 840 1 101 2 1 1 22 }

      KEA-Parms-Id     ::= OCTET STRING

   CAs MUST populate the parameters field of the AlgorithmIdentifier
   within the SubjectPublicKeyInfo field of each certificate containing
   a KEA public key with an 80-bit parameter identifier (OCTET STRING),
   also known as the domain identifier.  The domain identifier is
   computed in three steps:

      (1) the KEA domain parameters (p, q, and g) are DER encoded using
      the Dss-Parms structure;

      (2) a 160-bit SHA-1 hash is generated from the parameters; and

      (3) the 160-bit hash is reduced to 80-bits by performing an
      "exclusive or" of the 80 high order bits with the 80 low order
      bits.

   The resulting value is encoded such that the most significant byte of
   the 80-bit value is the first octet in the octet string.  The Dss-
   Parms is provided above in Section 2.3.2.

   A KEA public key, y, is conveyed in the subjectPublicKey BIT STRING
   such that the most significant bit (MSB) of y becomes the MSB of the
   BIT STRING value field and the least significant bit (LSB) of y
   becomes the LSB of the BIT STRING value field.  This results in the
   following encoding:

      BIT STRING tag;
      BIT STRING length;
      0 (indicating that there are zero unused bits in the final octet
      of y); and
      BIT STRING value field including y.

   The key usage extension may optionally appear in a KEA certificate.
   If a KEA certificate includes the keyUsage extension, only the
   following values may be asserted:

      keyAgreement;
      encipherOnly; and
      decipherOnly.





Polk, et al.                Standards Track                    [Page 12]

RFC 3279               Algorithms and Identifiers             April 2002


   If present, the keyUsage extension MUST assert keyAgreement and MAY
   assert either encipherOnly and decipherOnly.  The keyUsage extension
   MUST NOT assert both encipherOnly and decipherOnly.

2.3.5 ECDSA and ECDH Keys

   This section identifies the preferred OID and parameter encoding for
   the inclusion of an ECDSA or ECDH public key in a certificate.  The
   Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
   [X9.62].  ECDSA is the elliptic curve mathematical analog of the
   Digital Signature Algorithm [FIPS 186].  The Elliptic Curve Diffie
   Hellman (ECDH) algorithm is a key agreement algorithm defined in
   [X9.63].

   ECDH is the elliptic curve mathematical analog of the Diffie-Hellman
   key agreement algorithm as specified in [X9.42].  The ECDSA and ECDH
   specifications use the same OIDs and parameter encodings.  The ASN.1
   object identifiers used to identify these public keys are defined in
   the following arc:

   ansi-X9-62 OBJECT IDENTIFIER ::=
                             { iso(1) member-body(2) us(840) 10045 }

   When certificates contain an ECDSA or ECDH public key, the
   id-ecPublicKey algorithm identifier MUST be used. The id-ecPublicKey
   algorithm identifier is defined as follows:

     id-public-key-type OBJECT IDENTIFIER  ::= { ansi-X9.62 2 }

     id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

   This OID is used in public key certificates for both ECDSA signature
   keys and ECDH encryption keys.  The intended application for the key
   may be indicated in the key usage field (see [RFC 3280]).  The use of
   a single key for both signature and encryption purposes is not
   recommended, but is not forbidden.

   ECDSA and ECDH require use of certain parameters with the public key.
   The parameters may be inherited from the issuer, implicitly included
   through reference to a "named curve," or explicitly included in the
   certificate.

      EcpkParameters ::= CHOICE {
        ecParameters  ECParameters,
        namedCurve    OBJECT IDENTIFIER,
        implicitlyCA  NULL }





Polk, et al.                Standards Track                    [Page 13]

RFC 3279               Algorithms and Identifiers             April 2002


   When the parameters are inherited, the parameters field SHALL contain
   implictlyCA, which is the ASN.1 value NULL.  When parameters are
   specified by reference, the parameters field SHALL contain the
   named-Curve choice, which is an object identifier.  When the
   parameters are explicitly included, they SHALL be encoded in the
   ASN.1 structure ECParameters:

      ECParameters ::= SEQUENCE {
         version   ECPVer,          -- version is always 1
         fieldID   FieldID,         -- identifies the finite field over
                                    -- which the curve is defined
         curve     Curve,           -- coefficients a and b of the
                                    -- elliptic curve
         base      ECPoint,         -- specifies the base point P
                                    -- on the elliptic curve
         order     INTEGER,         -- the order n of the base point
         cofactor  INTEGER OPTIONAL -- The integer h = #E(Fq)/n
         }

      ECPVer ::= INTEGER {ecpVer1(1)}

      Curve ::= SEQUENCE {
         a         FieldElement,
         b         FieldElement,
         seed      BIT STRING OPTIONAL }

      FieldElement ::= OCTET STRING

      ECPoint ::= OCTET STRING

   The value of FieldElement SHALL be the octet string representation of
   a field element following the conversion routine in [X9.62], Section
   4.3.3.  The value of ECPoint SHALL be the octet string representation
   of an elliptic curve point following the conversion routine in
   [X9.62], Section 4.3.6.  Note that this octet string may represent an
   elliptic curve point in compressed or uncompressed form.

   Implementations that support elliptic curve according to this
   specification MUST support the uncompressed form and MAY support the
   compressed form.

   The components of type ECParameters have the following meanings:

      version specifies the version number of the elliptic curve
      parameters.  It MUST have the value 1 (ecpVer1).






Polk, et al.                Standards Track                    [Page 14]

RFC 3279               Algorithms and Identifiers             April 2002


      fieldID identifies the finite field over which the elliptic curve
      is defined.  Finite fields are represented by values of the
      parameterized type FieldID, constrained to the values of the
      objects defined in the information object set FieldTypes.
      Additional detail regarding fieldID is provided below.

      curve specifies the coefficients a and b of the elliptic curve E.
      Each coefficient is represented as a value of type FieldElement,
      an OCTET STRING. seed is an optional parameter used to derive the
      coefficients of a randomly generated elliptic curve.

      base specifies the base point P on the elliptic curve.  The base
      point is represented as a value of type ECPoint, an OCTET STRING.

      order specifies the order n of the base point.

      cofactor is the integer h = #E(Fq)/n.  This parameter is specified
      as OPTIONAL.  However, the cofactor MUST be included in ECDH
      public key parameters.  The cofactor is not required to support
      ECDSA, except in parameter validation.  The cofactor MAY be
      included to support parameter validation for ECDSA keys.
      Parameter validation is not required by this specification.

   The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place
   within a certificate where the parameters may be used.  If the
   elliptic curve parameters are specified as implicitlyCA in the
   SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
   subject certificate using ECDSA, then the certificate issuer's ECDSA
   parameters apply to the subject's ECDSA key.  If the elliptic curve
   parameters are specified as implicitlyCA in the SubjectPublicKeyInfo
   AlgorithmIdentifier and the CA signed the certificate using a
   signature algorithm other than ECDSA, then clients MUST not make use
   of the elliptic curve public key.

      FieldID ::= SEQUENCE {
         fieldType   OBJECT IDENTIFIER,
         parameters  ANY DEFINED BY fieldType }

   FieldID is a SEQUENCE of two components, fieldType and parameters.
   The fieldType contains an object identifier value that uniquely
   identifies the type contained in the parameters.

   The object identifier id-fieldType specifies an arc containing the
   object identifiers of each field type.  It has the following value:

      id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }





Polk, et al.                Standards Track                    [Page 15]

RFC 3279               Algorithms and Identifiers             April 2002


   The object identifiers prime-field and characteristic-two-field name
   the two kinds of fields defined in this Standard.  They have the
   following values:

      prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }

      Prime-p ::= INTEGER    -- Field size p (p in bits)

      characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }

      Characteristic-two ::= SEQUENCE {
         m           INTEGER,                      -- Field size 2^m
         basis       OBJECT IDENTIFIER,
         parameters  ANY DEFINED BY basis }

   The object identifier id-characteristic-two-basis specifies an arc
   containing the object identifiers for each type of basis for the
   characteristic-two finite fields.  It has the following value:

      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(1) }

   The object identifiers gnBasis, tpBasis and ppBasis name the three
   kinds of basis for characteristic-two finite fields defined by
   [X9.62].  They have the following values:

      gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }

      -- for gnBasis, the value of the parameters field is NULL

      tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }

      -- type of parameters field for tpBasis is Trinomial

      Trinomial ::= INTEGER

      ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }

      -- type of parameters field for ppBasis is Pentanomial

      Pentanomial ::= SEQUENCE {
         k1  INTEGER,
         k2  INTEGER,
         k3  INTEGER }







Polk, et al.                Standards Track                    [Page 16]

RFC 3279               Algorithms and Identifiers             April 2002


   The elliptic curve public key (an ECPoint which is an OCTET STRING)
   is mapped to a subjectPublicKey (a BIT STRING) as follows:  the most
   significant bit of the OCTET STRING becomes the most significant bit
   of the BIT STRING, and the least significant bit of the OCTET STRING
   becomes the least significant bit of the BIT STRING.  Note that this
   octet string may represent an elliptic curve point in compressed or
   uncompressed form.  Implementations that support elliptic curve
   according to this specification MUST support the uncompressed form
   and MAY support the compressed form.

   If the keyUsage extension is present in a CA or CRL issuer
   certificate which conveys an elliptic curve public key, any
   combination of the following values MAY be present:

      digitalSignature;
      nonRepudiation; and
      keyAgreement.

   If the keyAgreement value is present, either of the following values
   MAY be present:

      encipherOnly; and
      decipherOnly.

   The keyUsage extension MUST NOT assert both encipherOnly and
   decipherOnly.

   If the keyUsage extension is present in a CA certificate which
   conveys an elliptic curve public key, any combination of the
   following values MAY be present:

      digitalSignature;
      nonRepudiation;
      keyAgreement;
      keyCertSign; and
      cRLSign.

   As above, if the keyUsage extension asserts keyAgreement then it MAY
   assert either encipherOnly and decipherOnly.  However, this
   specification RECOMMENDS that if keyCertSign or cRLSign is present,
   keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.










Polk, et al.                Standards Track                    [Page 17]

RFC 3279               Algorithms and Identifiers             April 2002


3  ASN.1 Module

   PKIX1Algorithms88 { iso(1) identified-organization(3) dod(6)
   internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
   id-mod-pkix1-algorithms(17) }

   DEFINITIONS EXPLICIT TAGS ::= BEGIN

   -- EXPORTS All;

   -- IMPORTS NONE;

   --
   --   One-way Hash Functions
   --

   md2  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549)
     digestAlgorithm(2) 2 }

   md5  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549)
     digestAlgorithm(2) 5 }

   id-sha1  OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) oiw(14) secsig(3)
     algorithms(2) 26 }

   --
   --   DSA Keys and Signatures
   --

   -- OID for DSA public key

   id-dsa OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }

   -- encoding for DSA public key

   DSAPublicKey ::= INTEGER  -- public key, y

   Dss-Parms  ::=  SEQUENCE  {
      p             INTEGER,
      q             INTEGER,
      g             INTEGER  }






Polk, et al.                Standards Track                    [Page 18]

RFC 3279               Algorithms and Identifiers             April 2002


   -- OID for DSA signature generated with SHA-1 hash

   id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {
        iso(1) member-body(2) us(840) x9-57 (10040) x9algorithm(4) 3 }

   -- encoding for DSA signature generated with SHA-1 hash

   Dss-Sig-Value  ::=  SEQUENCE  {
      r       INTEGER,
      s       INTEGER  }

   --
   --   RSA Keys and Signatures
   --

   -- arc for RSA public key and RSA signature OIDs

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

   -- OID for RSA public keys

   rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1 }

   -- OID for RSA signature generated with MD2 hash

   md2WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 2 }

   -- OID for RSA signature generated with MD5 hash

   md5WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 4 }

   -- OID for RSA signature generated with SHA-1 hash

   sha1WithRSAEncryption OBJECT IDENTIFIER  ::=  { pkcs-1 5 }

   -- encoding for RSA public key

   RSAPublicKey ::= SEQUENCE {
      modulus            INTEGER,    -- n
      publicExponent     INTEGER  }  -- e










Polk, et al.                Standards Track                    [Page 19]

RFC 3279               Algorithms and Identifiers             April 2002


   --
   --   Diffie-Hellman Keys
   --

   dhpublicnumber OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) ansi-x942(10046)
        number-type(2) 1 }

   -- encoding for DSA public key

   DHPublicKey ::= INTEGER  -- public key, y = g^x mod p

   DomainParameters ::= SEQUENCE {
      p       INTEGER,           -- odd prime, p=jq +1
      g       INTEGER,           -- generator, g
      q       INTEGER,           -- factor of p-1
      j       INTEGER OPTIONAL,  -- subgroup factor, j>= 2
      validationParms  ValidationParms OPTIONAL }

   ValidationParms ::= SEQUENCE {
      seed             BIT STRING,
      pgenCounter      INTEGER }

   --
   --   KEA Keys
   --

   id-keyExchangeAlgorithm  OBJECT IDENTIFIER  ::=
        { 2 16 840 1 101 2 1 1 22 }

   KEA-Parms-Id ::= OCTET STRING

   --
   --   Elliptic Curve Keys, Signatures, and Curves
   --

   ansi-X9-62 OBJECT IDENTIFIER ::= {
        iso(1) member-body(2) us(840) 10045 }

   FieldID ::= SEQUENCE {                    -- Finite field
      fieldType   OBJECT IDENTIFIER,
      parameters  ANY DEFINED BY fieldType }

   -- Arc for ECDSA signature OIDS

   id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }





Polk, et al.                Standards Track                    [Page 20]

RFC 3279               Algorithms and Identifiers             April 2002


   -- OID for ECDSA signatures with SHA-1

   ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { id-ecSigType 1 }

   -- OID for an elliptic curve signature
   -- format for the value of an ECDSA signature value

   ECDSA-Sig-Value ::= SEQUENCE {
      r     INTEGER,
      s     INTEGER }

   -- recognized field type OIDs are defined in the following arc

   id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }

   -- where fieldType is prime-field, the parameters are of type Prime-p

   prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }

   Prime-p ::= INTEGER -- Finite field F(p), where p is an odd prime

   -- where fieldType is characteristic-two-field, the parameters are
   -- of type Characteristic-two

   characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }

   Characteristic-two ::= SEQUENCE {
      m           INTEGER,                   -- Field size 2^m
      basis       OBJECT IDENTIFIER,
      parameters  ANY DEFINED BY basis }

   -- recognized basis type OIDs are defined in the following arc

   id-characteristic-two-basis OBJECT IDENTIFIER ::= {
        characteristic-two-field basisType(3) }

   -- gnbasis is identified by OID gnBasis and indicates
   -- parameters are NULL

   gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }

   -- parameters for this basis are NULL

   -- trinomial basis is identified by OID tpBasis and indicates
   -- parameters of type Pentanomial

   tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }




Polk, et al.                Standards Track                    [Page 21]

RFC 3279               Algorithms and Identifiers             April 2002


   -- Trinomial basis representation of F2^m
   -- Integer k for reduction polynomial xm + xk + 1

   Trinomial ::= INTEGER

   -- for pentanomial basis is identified by OID ppBasis and indicates
   -- parameters of type Pentanomial

   ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }

   -- Pentanomial basis representation of F2^m
   -- reduction polynomial integers k1, k2, k3
   -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1

   Pentanomial ::= SEQUENCE {
      k1  INTEGER,
      k2  INTEGER,
      k3  INTEGER }

   -- The object identifiers gnBasis, tpBasis and ppBasis name
   -- three kinds of basis for characteristic-two finite fields

   FieldElement ::= OCTET STRING             -- Finite field element

   ECPoint  ::= OCTET STRING                 -- Elliptic curve point

   -- Elliptic Curve parameters may be specified explicitly,
   -- specified implicitly through a "named curve", or
   -- inherited from the CA

   EcpkParameters ::= CHOICE {
      ecParameters  ECParameters,
      namedCurve    OBJECT IDENTIFIER,
      implicitlyCA  NULL }

   ECParameters  ::= SEQUENCE {         -- Elliptic curve parameters
      version   ECPVer,
      fieldID   FieldID,
      curve     Curve,
      base      ECPoint,                -- Base point G
      order     INTEGER,                -- Order n of the base point
      cofactor  INTEGER  OPTIONAL }     -- The integer h = #E(Fq)/n

   ECPVer ::= INTEGER {ecpVer1(1)}







Polk, et al.                Standards Track                    [Page 22]

RFC 3279               Algorithms and Identifiers             April 2002


   Curve  ::= SEQUENCE {
      a     FieldElement,            -- Elliptic curve coefficient a
      b     FieldElement,            -- Elliptic curve coefficient b
      seed  BIT STRING  OPTIONAL }

   id-publicKeyType OBJECT IDENTIFIER  ::= { ansi-X9-62 keyType(2) }

   id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

   -- Named Elliptic Curves in ANSI X9.62.

   ellipticCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) }

   c-TwoCurve OBJECT IDENTIFIER ::= {
        ellipticCurve characteristicTwo(0) }

   c2pnb163v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  1 }
   c2pnb163v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  2 }
   c2pnb163v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  3 }
   c2pnb176w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  4 }
   c2tnb191v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve  5 }
   c2tnb191v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve  6 }
   c2tnb191v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve  7 }
   c2onb191v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve  8 }
   c2onb191v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve  9 }
   c2pnb208w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 10 }
   c2tnb239v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 11 }
   c2tnb239v2  OBJECT IDENTIFIER  ::=  { c-TwoCurve 12 }
   c2tnb239v3  OBJECT IDENTIFIER  ::=  { c-TwoCurve 13 }
   c2onb239v4  OBJECT IDENTIFIER  ::=  { c-TwoCurve 14 }
   c2onb239v5  OBJECT IDENTIFIER  ::=  { c-TwoCurve 15 }
   c2pnb272w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 16 }
   c2pnb304w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 17 }
   c2tnb359v1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 18 }
   c2pnb368w1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 19 }
   c2tnb431r1  OBJECT IDENTIFIER  ::=  { c-TwoCurve 20 }

   primeCurve OBJECT IDENTIFIER ::= { ellipticCurve prime(1) }

   prime192v1  OBJECT IDENTIFIER  ::=  { primeCurve  1 }
   prime192v2  OBJECT IDENTIFIER  ::=  { primeCurve  2 }
   prime192v3  OBJECT IDENTIFIER  ::=  { primeCurve  3 }
   prime239v1  OBJECT IDENTIFIER  ::=  { primeCurve  4 }
   prime239v2  OBJECT IDENTIFIER  ::=  { primeCurve  5 }
   prime239v3  OBJECT IDENTIFIER  ::=  { primeCurve  6 }
   prime256v1  OBJECT IDENTIFIER  ::=  { primeCurve  7 }

   END



Polk, et al.                Standards Track                    [Page 23]

RFC 3279               Algorithms and Identifiers             April 2002


4  References

   [FIPS 180-1]   Federal Information Processing Standards Publication
                  (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
                  [Supersedes FIPS PUB 180 dated 11 May 1993.]

   [FIPS 186-2]   Federal Information Processing Standards Publication
                  (FIPS PUB) 186, Digital Signature Standard, 27 January
                  2000. [Supersedes FIPS PUB 186-1 dated 15 December
                  1998.]

   [P1363]        IEEE P1363, "Standard Specifications for Public-Key
                  Cryptography", 2001.

   [RC95]         Rogier, N. and Chauvaud, P., "The compression function
                  of MD2 is not collision free," Presented at Selected
                  Areas in Cryptography '95, May 1995.

   [RFC 1034]     Mockapetris, P., "Domain Names - Concepts and
                  Facilities", STD 13, RFC 1034, November 1987.

   [RFC 1319]     Kaliski, B., "The MD2 Message-Digest Algorithm", RFC
                  1319, April 1992.

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

   [RFC 1422]     Kent, S., "Privacy Enhancement for Internet Electronic
                  Mail: Part II: Certificate-Based Key Management", RFC
                  1422, February 1993.

   [RFC 1423]     Balenson, D., "Privacy Enhancement for Internet
                  Electronic Mail: Part III: Algorithms, Modes, and
                  Identifiers", RFC 1423, February 1993.

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

   [RFC 2313]     Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
                  RFC 2313, March 1998.

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

   [RFC 3174]     Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
                  (SHA1)", RFC 3174, September 2001.




Polk, et al.                Standards Track                    [Page 24]

RFC 3279               Algorithms and Identifiers             April 2002


   [RFC 3280]     Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
                  X.509 Public Key Infrastructure Certificate and
                  Certificate Revocation List (CRL) Profile", RFC 3280,
                  April 2002.

   [SDN.701r]     SDN.701, "Message Security Protocol 4.0", Revision A
                  1997-02-06.

   [X.208]        CCITT Recommendation X.208: Specification of Abstract
                  Syntax Notation One (ASN.1), 1988.

   [X.660]        ITU-T Recommendation X.660 Information Technology -
                  ASN.1 encoding rules: Specification of Basic Encoding
                  Rules (BER), Canonical Encoding Rules (CER) and
                  Distinguished Encoding Rules (DER), 1997.

   [X9.42]        ANSI X9.42-2000, "Public Key Cryptography for The
                  Financial Services Industry: Agreement of Symmetric
                  Keys Using Discrete Logarithm Cryptography", December,
                  1999.

   [X9.62]        X9.62-1998, "Public Key Cryptography For The Financial
                  Services Industry: The Elliptic Curve Digital
                  Signature Algorithm (ECDSA)", January 7, 1999.

   [X9.63]        ANSI X9.63-2001, "Public Key Cryptography For The
                  Financial Services Industry: Key Agreement and Key
                  Transport Using Elliptic Curve Cryptography", Work in
                  Progress.

5  Security Considerations

   This specification does not constrain the size of public keys or
   their parameters for use in the Internet PKI.  However, the key size
   selected impacts the strength achieved when implementing
   cryptographic services.  Selection of appropriate key sizes is
   critical to implementing appropriate security.

   This specification does not identify particular elliptic curves for
   use in the Internet PKI.  However, the particular curve selected
   impact the strength of the digital signatures.  Some curves are
   cryptographically stronger than others!

   In general, use of "well-known" curves, such as the "named curves"
   from ANSI X9.62, is a sound strategy.  For additional information,
   refer to X9.62 Appendix H.1.3, "Key Length Considerations" and
   Appendix A.1, "Avoiding Cryptographically Weak Keys".




Polk, et al.                Standards Track                    [Page 25]

RFC 3279               Algorithms and Identifiers             April 2002


   This specification supplements RFC 3280.  The security considerations
   section of that document applies to this specification as well.

6  Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights.

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards- related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

7  Author Addresses:

   Tim Polk
   NIST
   100 Bureau Drive, Stop 8930
   Gaithersburg, MD 20899-8930
   USA
   EMail: tim.polk@nist.gov

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   EMail: rhousley@rsasecurity.com

   Larry Bassham
   NIST
   100 Bureau Drive, Stop 8930
   Gaithersburg, MD 20899-8930
   USA
   EMail: lbassham@nist.gov





Polk, et al.                Standards Track                    [Page 26]

RFC 3279               Algorithms and Identifiers             April 2002


8.  Full Copyright Statement

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



















Polk, et al.                Standards Track                    [Page 27]