File: rfc2986.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 (787 lines) | stat: -rw-r--r-- 27,794 bytes parent folder | download | duplicates (6)
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






Network Working Group                                         M. Nystrom
Request for Comments: 2986                                    B. Kaliski
Obsoletes: 2314                                             RSA Security
Category: Informational                                    November 2000


          PKCS #10: Certification Request Syntax Specification
                              Version 1.7

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

   This memo represents a republication of PKCS #10 v1.7 from RSA
   Laboratories' Public-Key Cryptography Standards (PKCS) series, and
   change control is retained within the PKCS process.  The body of this
   document, except for the security considerations section, is taken
   directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document.

   This memo describes a syntax for certification requests.

Table of Contents

   1.  Introduction ................................................. 2
   2.  Definitions and notation ..................................... 2
   2.1  Definitions ................................................. 2
   2.2  Notation .................................................... 4
   3.  Overview ..................................................... 4
   4.  Certification request syntax ................................. 5
   4.1  CertificationRequestInfo .................................... 5
   4.2  CertificationRequest ........................................ 7
   5.  Security Considerations ...................................... 8
   6.  Authors' Addresses ........................................... 8
   A.  ASN.1 module ................................................. 9
   B.  Intellectual property considerations ........................ 10
   C.  Revision history ............................................ 10
   D.  References .................................................. 11
   E.  Contact information & About PKCS ............................ 12
   Full Copyright Statement ........................................ 14




Nystrom & Kaliski            Informational                      [Page 1]

RFC 2986       Certification Request Syntax Specification  November 2000


1. Introduction

   This document describes syntax for certification requests.  A
   certification request consists of a distinguished name, a public key,
   and optionally a set of attributes, collectively signed by the entity
   requesting certification.  Certification requests are sent to a
   certification authority, which transforms the request into an X.509
   [9] public-key certificate.  (In what form the certification
   authority returns the newly signed certificate is outside the scope
   of this document.  A PKCS #7 [2] message is one possibility.)

   The intention of including a set of attributes is twofold: to provide
   other information about a given entity , or a "challenge password" by
   which the entity may later request certificate revocation; and to
   provide attributes for inclusion in X.509 certificates.  A non-
   exhaustive list of attributes is given in PKCS #9 [3].

   Certification authorities may also require non-electronic forms of
   request and may return non-electronic replies.  It is expected that
   descriptions of such forms, which are outside the scope of this
   document, will be available from certification authorities.

   The preliminary intended application of this document is to support
   PKCS #7 cryptographic messages, but it is expected that other
   applications will be developed (see e.g. [4]).

2. Definitions and notation

 2.1 Definitions

   For the purposes of this document, the following definitions apply.

   ALGORITHM       An information object class defined in X.509 to
                   describe objects composed of an algorithm (a unique
                   object identifier) and its parameters (any ASN.1
                   type).  The values of objects in this class can be
                   represented by the ASN.1 type AlgorithmIdentifier{}.
                   ALGORITHM is defined as the "useful" information
                   object class TYPE-IDENTIFIER, specified in [11],
                   Annex A.

   AlgorithmIdentifier{}
                   A useful parameterized version of X.509 type
                   AlgorithmIdentifier is defined in this document.
                   This type tightly binds pairs of algorithm object
                   identifiers to their associated parameter types.
                   When referenced, the single parameter of
                   AlgorithmIdentifier{} specifies a constraint on the



Nystrom & Kaliski            Informational                      [Page 2]

RFC 2986       Certification Request Syntax Specification  November 2000


                   pairs of values that may appear in that instance of
                   the type.  The encoded values of
                   AlgorithmIdentifier{} are equivalent to those of type
                   AlgorithmIdentifier.

   ASN.1           Abstract Syntax Notation One, as defined in the ASN.1
                   standards ([10], [11], [12], and [13]).

   ATTRIBUTE       This class describes objects composed of an attribute
                   (a unique object identifier) and an associated set of
                   attribute values (any ASN.1 type).  The values of
                   objects in this class can be represented by type
                   Attribute{}.

   Attribute{}     A useful parameterized version of X.501 [8] type
                   Attribute is defined in this document.  This type
                   tightly binds pairs of attribute type object
                   identifiers to one or more attribute values types.
                   In the ASN.1 open type notation, an attribute type is
                   defined as ATTRIBUTE.&id and an attribute value as
                   ATTRIBUTE.&Type.  When referenced, the single
                   parameter of Attribute{} specifies a constraint on
                   the pairs of values that may appear in an instance of
                   the type.  The encoded values of Attribute{} are
                   equivalent to those of type Attribute.

   BER             Basic Encoding Rules for ASN.1, as defined in X.690
                   ([14]).

   Certificate     A type that binds a subject entity's distinguished
                   name to a public key with a digital signature.  This
                   type is defined in X.509.  This type also contains
                   the distinguished name of the certificate issuer (the
                   signer), an issuer-specific serial number, the
                   issuer's signature algorithm identifier, a validity
                   period, and an optional set of certificate
                   extensions.

   DER             Distinguished Encoding Rules for ASN.1, as defined in
                   X.690.  DER is a subset of BER.

   Name            A type that uniquely identifies or "distinguishes"
                   objects in an X.500 [7] directory.  This type is
                   defined in X.501.  In an X.509 certificate, the type
                   identifies the certificate issuer and the certificate
                   subject, the entity whose public key is certified.





Nystrom & Kaliski            Informational                      [Page 3]

RFC 2986       Certification Request Syntax Specification  November 2000


  2.2 Notation

   No special notation is used in this document.

3. Overview

   A certification request consists of three parts: "certification
   request information," a signature algorithm identifier, and a digital
   signature on the certification request information.  The
   certification request information consists of the entity's
   distinguished name, the entity's public key, and a set of attributes
   providing other information about the entity.

   The process by which a certification request is constructed involves
   the following steps:

        1. A CertificationRequestInfo value containing a subject
           distinguished name, a subject public key, and optionally a
           set of attributes is constructed by an entity requesting
           certification.

        2. The CertificationRequestInfo value is signed with the subject
           entity's private key.  (See Section 4.2.)

        3. The CertificationRequestInfo value, a signature algorithm
           identifier, and the entity's signature are collected together
           into a CertificationRequest value, defined below.

   A certification authority fulfills the request by authenticating the
   requesting entity and verifying the entity's signature, and, if the
   request is valid, constructing an X.509 certificate from the
   distinguished name and public key, the issuer name, and the
   certification authority's choice of serial number, validity period,
   and signature algorithm.  If the certification request contains any
   PKCS #9 attributes, the certification authority may also use the
   values in these attributes as well as other information known to the
   certification authority to construct X.509 certificate extensions.

   In what form the certification authority returns the new certificate
   is outside the scope of this document.  One possibility is a PKCS #7
   cryptographic message with content type signedData, following the
   degenerate case where there are no signers.  The return message may
   include a certification path from the new certificate to the
   certification authority.  It may also include other certificates such
   as cross-certificates that the certification authority considers
   helpful, and it may include certificate-revocation lists (CRLs).
   Another possibility is that the certification authority inserts the
   new certificate into a central database.



Nystrom & Kaliski            Informational                      [Page 4]

RFC 2986       Certification Request Syntax Specification  November 2000


   Note 1 - An entity would typically send a certification request after
   generating a public-key/private-key pair, but may also do so after a
   change in the entity's distinguished name.

   Note 2 - The signature on the certification request prevents an
   entity from requesting a certificate with another party's public key.
   Such an attack would give the entity the minor ability to pretend to
   be the originator of any message signed by the other party.  This
   attack is significant only if the entity does not know the message
   being signed and the signed part of the message does not identify the
   signer.  The entity would still not be able to decrypt messages
   intended for the other party, of course.

   Note 3 - How the entity sends the certification request to a
   certification authority is outside the scope of this document.  Both
   paper and electronic forms are possible.

   Note 4 - This document is not compatible with the certification
   request syntax for Privacy-Enhanced Mail, as described in RFC 1424
   [5].  The syntax here differs in three respects: It allows a set of
   attributes; it does not include issuer name, serial number, or
   validity period; and it does not require an "innocuous" message to be
   signed.  This document is designed to minimize request size, an
   important feature for certification authorities accepting requests on
   paper.

4. Certification request syntax

   This section is divided into two parts.  The first part describes the
   certification-request-information type CertificationRequestInfo, and
   the second part describes the top-level type CertificationRequest.

 4.1 CertificationRequestInfo

   Certification request information shall have ASN.1 type
   CertificationRequestInfo:

   CertificationRequestInfo ::= SEQUENCE {
        version       INTEGER { v1(0) } (v1,...),
        subject       Name,
        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
        attributes    [0] Attributes{{ CRIAttributes }}
   }

   SubjectPublicKeyInfo { ALGORITHM : IOSet} ::= SEQUENCE {
        algorithm        AlgorithmIdentifier {{IOSet}},
        subjectPublicKey BIT STRING
   }



Nystrom & Kaliski            Informational                      [Page 5]

RFC 2986       Certification Request Syntax Specification  November 2000


   PKInfoAlgorithms ALGORITHM ::= {
        ...  -- add any locally defined algorithms here -- }

   Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}

   CRIAttributes  ATTRIBUTE  ::= {
        ... -- add any locally defined attributes here -- }

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
   }

   The components of type CertificationRequestInfo have the following
   meanings:

        version is the version number, for compatibility with future
          revisions of this document.  It shall be 0 for this version of
          the standard.

        subject is the distinguished name of the certificate subject
          (the entity whose public key is to be certified).

        subjectPublicKeyInfo contains information about the public key
          being certified.  The information identifies the entity's
          public-key algorithm (and any associated parameters); examples
          of public-key algorithms include the rsaEncryption object
          identifier from PKCS #1 [1].  The information also includes a
          bit-string representation of the entity's public key.  For the
          public-key algorithm just mentioned, the bit string contains
          the DER encoding of a value of PKCS #1 type RSAPublicKey.  The
          values of type SubjectPublicKeyInfo{} allowed for
          subjectPKInfo are constrained to the values specified by the
          information object set PKInfoAlgorithms, which includes the
          extension marker (...).  Definitions of specific algorithm
          objects are left to specifications that reference this
          document.  Such specifications will be interoperable with
          their future versions if any additional algorithm objects are
          added after the extension marker.

        attributes is a collection of attributes providing additional
          information about the subject of the certificate.  Some
          attribute types that might be useful here are defined in PKCS
          #9.  An example is the challenge-password attribute, which
          specifies a password by which the entity may request
          certificate revocation.  Another example is information to
          appear in X.509 certificate extensions (e.g. the
          extensionRequest attribute from PKCS #9).  The values of type



Nystrom & Kaliski            Informational                      [Page 6]

RFC 2986       Certification Request Syntax Specification  November 2000


          Attributes{} allowed for attributes are constrained to the
          values specified by the information object set CRIAttributes.
          Definitions of specific attribute objects are left to
          specifications that reference this document.  Such
          specifications will be interoperable with their future
          versions if any additional attribute objects are added after
          the extension marker.

 4.2 CertificationRequest

   A certification request shall have ASN.1 type CertificationRequest:

   CertificationRequest ::= SEQUENCE {
        certificationRequestInfo CertificationRequestInfo,
        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
        signature          BIT STRING
   }

   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
        algorithm          ALGORITHM.&id({IOSet}),
        parameters         ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
   }

   SignatureAlgorithms ALGORITHM ::= {
        ... -- add any locally defined algorithms here -- }

   The components of type CertificationRequest have the following
   meanings:

        certificateRequestInfo is the "certification request
          information." It is the value being signed.

        signatureAlgorithm identifies the signature algorithm (and any
          associated parameters) under which the certification-request
          information is signed.  For example, a specification might
          include an ALGORITHM object for PKCS #1's
          md5WithRSAEncryption in the information object set
          SignatureAlgorithms:

          SignatureAlgorithms ALGORITHM ::= {
               ...,
               { NULL IDENTIFIED BY md5WithRSAEncryption }
          }

        signature is the result of signing the certification request
          information with the certification request subject's private
          key.




Nystrom & Kaliski            Informational                      [Page 7]

RFC 2986       Certification Request Syntax Specification  November 2000


   The signature process consists of two steps:

        1. The value of the certificationRequestInfo component is DER
           encoded, yielding an octet string.

        2. The result of step 1 is signed with the certification request
           subject's private key under the specified signature
           algorithm, yielding a bit string, the signature.

   Note - An equivalent syntax for CertificationRequest could be
   written:

   CertificationRequest ::= SIGNED { EncodedCertificationRequestInfo }
        (CONSTRAINED BY { -- Verify or sign encoded
         -- CertificationRequestInfo -- })

   EncodedCertificationRequestInfo ::=
        TYPE-IDENTIFIER.&Type(CertificationRequestInfo)

   SIGNED { ToBeSigned } ::= SEQUENCE {
        toBeSigned ToBeSigned,
        algorithm  AlgorithmIdentifier { {SignatureAlgorithms} },
        signature  BIT STRING
   }

5. Security Considerations

   Security issues are discussed throughout this memo.

6. Authors' Addresses

   Magnus Nystrom
   RSA Security
   Box 10704
   S-121 29 Stockholm
   Sweden

   EMail: magnus@rsasecurity.com


   Burt Kaliski
   RSA Security
   20 Crosby Drive
   Bedford, MA 01730 USA

   EMail: bkaliski@rsasecurity.com





Nystrom & Kaliski            Informational                      [Page 8]

RFC 2986       Certification Request Syntax Specification  November 2000


APPENDICES

A. ASN.1 Module

   This appendix includes all of the ASN.1 type and value definitions
   contained in this document in the form of the ASN.1 module PKCS-10.

   PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
   pkcs-10(10) modules(1) pkcs-10(1)}

   DEFINITIONS IMPLICIT TAGS ::=

   BEGIN

   -- EXPORTS All --

   -- All types and values defined in this module are exported for use
   -- in other ASN.1 modules.

   IMPORTS

   informationFramework, authenticationFramework
        FROM UsefulDefinitions {joint-iso-itu-t(2) ds(5) module(1)
        usefulDefinitions(0) 3}

   ATTRIBUTE, Name
        FROM InformationFramework informationFramework

   ALGORITHM
        FROM AuthenticationFramework authenticationFramework;

   -- Certificate requests
   CertificationRequestInfo ::= SEQUENCE {
        version       INTEGER { v1(0) } (v1,...),
        subject       Name,
        subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
        attributes    [0] Attributes{{ CRIAttributes }}
   }

   SubjectPublicKeyInfo {ALGORITHM: IOSet} ::= SEQUENCE {
        algorithm        AlgorithmIdentifier {{IOSet}},
        subjectPublicKey BIT STRING
   }

   PKInfoAlgorithms ALGORITHM ::= {
        ...  -- add any locally defined algorithms here -- }

   Attributes { ATTRIBUTE:IOSet } ::= SET OF Attribute{{ IOSet }}



Nystrom & Kaliski            Informational                      [Page 9]

RFC 2986       Certification Request Syntax Specification  November 2000


   CRIAttributes  ATTRIBUTE  ::= {
        ... -- add any locally defined attributes here -- }

   Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
        type   ATTRIBUTE.&id({IOSet}),
        values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type})
   }

   CertificationRequest ::= SEQUENCE {
        certificationRequestInfo CertificationRequestInfo,
        signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
        signature          BIT STRING
   }

   AlgorithmIdentifier {ALGORITHM:IOSet } ::= SEQUENCE {
        algorithm  ALGORITHM.&id({IOSet}),
        parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
   }

   SignatureAlgorithms ALGORITHM ::= {
        ... -- add any locally defined algorithms here -- }

   END

B. Intellectual property considerations

   RSA Security makes no patent claims on the general constructions
   described in this document, although specific underlying techniques
   may be covered.

   License to copy this document is granted provided that it is
   identified as "RSA Security Inc.  Public-Key Cryptography Standards
   (PKCS)" in all material mentioning or referencing this document.

   RSA Security makes no representations regarding intellectual property
   claims by other parties.  Such determination is the responsibility of
   the user.

C. Revision history

   Version 1.0

         Version 1.0 was the previous version of this document (also
         published as "version 1.5" in [6]).







Nystrom & Kaliski            Informational                     [Page 10]

RFC 2986       Certification Request Syntax Specification  November 2000


   Version 1.7

         This version incorporates several editorial changes, including
         updates to the references, and changes to ASN.1 type
         definitions.  The following substantive changes have been made:

         - This version refers to X.680-X.690, the current international
           standards for ASN.1 and its encoding rules.  All references
           to X.208 and X.209 have been eliminated.

         - The X.690 standard requires that the encoded values of SET OF
           components be sorted in ascending order under DER.
           Regardless of this, applications should not rely on the
           ordering of attribute components.

         - All references to PKCS #6 Extended-Certificate Syntax
           Standard have been removed.  With the addition of extensions
           to X.509 version 3 certificates, RSA Laboratories is
           withdrawing support for PKCS #6.

   Note - The reason for using version 1.7 for this document is to avoid
   confusion with [6], which is named version 1.5, and an unsupported
   PKCS #10 version named Version 1.6.

D. References

   [1]  RSA Laboratories. PKCS #1: RSA Encryption Standard. Version 2.0,
        October 1998.

   [2]  RSA Laboratories. PKCS #7: Cryptographic Message Syntax
        Standard.  Version 1.5, November 1993.

   [3]  RSA Laboratories. PKCS #9: Selected Attribute Types. Version
        2.0, February 2000.

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

   [5]  Kaliski, B., "Privacy Enhancement for Internet Electronic Mail:
        Part IV: Key Certification and Related Services", RFC 1424,
        February 1993.

   [6]  Kaliski, B., "PKCS #10: Certification Request Syntax Version
        1.5", RFC 2314, March 1998.






Nystrom & Kaliski            Informational                     [Page 11]

RFC 2986       Certification Request Syntax Specification  November 2000


   [7]  ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1998,
        Information technology - Open Systems Interconnection - The
        Directory: Overview of concepts, models and services.

   [8]  ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1995,
        Information technology - Open Systems Interconnection - The
        Directory: Models.

   [9]  ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
        Information technology - Open Systems Interconnection -The
        Directory:  Authentication framework.

   [10] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998,
        Information Technology - Abstract Syntax Notation One (ASN.1):
        Specification of Basic Notation.

   [11] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998,
        Information Technology - Abstract Syntax Notation One (ASN.1):
        Information Object Specification.

   [12] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998,
        Information Technology - Abstract Syntax Notation One (ASN.1):
        Constraint Specification.

   [13] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998,
        Information Technology - Abstract Syntax Notation One (ASN.1):
        Parameterization of ASN.1 Specifications.

   [14] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998,
        Information Technology - ASN.1 Encoding Rules: Specification of
        Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
        Distinguished Encoding Rules (DER).

E. Contact Information & About PKCS

   The Public-Key Cryptography Standards are specifications produced by
   RSA Laboratories in cooperation with secure systems developers
   worldwide for the purpose of accelerating the deployment of public-
   key cryptography.  First published in 1991 as a result of meetings
   with a small group of early adopters of public-key technology, the
   PKCS documents have become widely referenced and implemented.
   Contributions from the PKCS series have become part of many formal
   and de facto standards, including ANSI X9 documents, PKIX, SET,
   S/MIME, and SSL.







Nystrom & Kaliski            Informational                     [Page 12]

RFC 2986       Certification Request Syntax Specification  November 2000


   Further development of PKCS occurs through mailing list discussions
   and occasional workshops, and suggestions for improvement are
   welcome.  For more information, contact:

        PKCS Editor
        RSA Laboratories
        20 Crosby Drive
        Bedford, MA  01730 USA
        pkcs-editor@rsasecurity.com
        http://www.rsasecurity.com/rsalabs/pkcs









































Nystrom & Kaliski            Informational                     [Page 13]

RFC 2986       Certification Request Syntax Specification  November 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 provided that the above copyright notice and this paragraph
   are included on all such copies.  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 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.

























Nystrom & Kaliski            Informational                     [Page 14]