File: rfc2559.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 (731 lines) | stat: -rw-r--r-- 22,894 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






Network Working Group                                      S. Boeyen
Request for Comments: 2559                                   Entrust
Updates: 1778                                               T. Howes
Category: Standards Track                                   Netscape
                                                          P. Richard
                                                               Xcert
                                                          April 1999


                Internet X.509 Public Key Infrastructure
                     Operational Protocols - LDAPv2

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 (1999).  All Rights Reserved.

1.  Abstract

   The protocol described in this document is designed to satisfy some
   of the operational requirements within the Internet X.509 Public Key
   Infrastructure (IPKI).  Specifically, this document addresses
   requirements to provide access to Public Key Infrastructure (PKI)
   repositories for the purposes of retrieving PKI information and
   managing that same information.  The mechanism described in this
   document is based on the Lightweight Directory Access Protocol (LDAP)
   v2, defined in RFC 1777, defining a profile of that protocol for use
   within the IPKI and updates encodings for certificates and revocation
   lists from RFC 1778. Additional mechanisms addressing PKIX
   operational requirements are specified in separate documents.

   The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY'
   in this document are to be interpreted as described in RFC 2119.

2.  Introduction

   This specification is part of a multi-part standard for development
   of a Public Key Infrastructure (PKI) for the Internet. This
   specification addresses requirements to provide retrieval of X.509
   PKI information, including certificates and CRLs from a repository.
   This specification also addresses requirements to add, delete and



Boeyen, et al.              Standards Track                     [Page 1]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


   modify PKI information in a repository. A profile based on the LDAP
   version 2 protocol is provided to satisfy these requirements.

3.  Model

   The PKI components, as defined in PKIX Part 1, which are involved in
   PKIX operational protocol interactions include:

      -  End Entities
      -  Certification Authorities (CA)
      -  Repository

   End entities and CAs using LDAPv2, retrieve PKI information from the
   repository using a subset of the LDAPv2 protocol.

   CAs populate the repository with PKI information using a subset of
   the LDAPv2 protocol.

4.  Lightweight Directory Access Protocol (LDAP)

   The following sections examine the retrieval of PKI information from
   a repository and management of PKI information in a repository. A
   profile of the LDAPv2 protocol is defined for providing these
   services.

   Section 5 satisfies the requirement to retrieve PKI information (a
   certificate, CRL, or other information of interest) from an entry in
   the repository, where the retrieving entity (either an end entity or
   a CA) has knowledge of the name of the entry. This is termed
   "repository read".

   Section 6 satisfies the same requirement as 5 for the situation where
   the name of the entry is not known, but some other related
   information which may optionally be used as a filter against
   candidate entries in the repository, is known.  This is termed
   "repository search".

   Section 7 satisfies the requirement of CAs to add, delete and modify
   PKI information information (a certificate, CRL, or other information
   of interest)in the repository. This is termed "repository modify".

   The subset of LDAPv2 needed to support each of these functions is
   described below.  Note that the repository search service is a
   superset of the repository read service in terms of the LDAPv2
   functionality needed.

   Note that all tags are implicit by default in the ASN.1 definitions
   that follow.



Boeyen, et al.              Standards Track                     [Page 2]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


5.  LDAP Repository Read

   To retrieve information from an entry corresponding to the subject or
   issuer name of a certificate, requires a subset of the following
   three LDAP operations:

     BindRequest (and BindResponse)
     SearchRequest (and SearchResponse)
     UnbindRequest

   The subset of each REQUIRED operation is given below.

5.1.  Bind

5.1.1.  Bind Request

   The full LDAP v2 Bind Request is defined in RFC 1777.

   An application providing a LDAP repository read service MUST
   implement the following subset of this operation:

      BindRequest ::=
        [APPLICATION 0] SEQUENCE {
           version      INTEGER (2),
           name         LDAPDN, -- MUST accept NULL LDAPDN
           simpleauth [0] OCTET STRING  -- MUST accept NULL simple
           }

   An application providing a LDAP repository read service MAY implement
   other aspects of the BindRequest as well.

   Different services may have different security requirements.  Some
   services may allow anonymous search, others may require
   authentication. Those services allowing anonymous search may choose
   only to allow search based on certain criteria and not others.

   A LDAP repository read service SHOULD implement some level of
   anonymous search access. A LDAP repository read service MAY implement
   authenticated search access.

5.1.2.  Bind Response

   The full LDAPv2 BindResponse is described in RFC 1777.

   An application providing a LDAP repository read service MUST
   implement this entire protocol element, though only the following
   error codes may be returned from a Bind operation:




Boeyen, et al.              Standards Track                     [Page 3]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


       success                      (0),
       operationsError              (1),
       protocolError                (2),
       authMethodNotSupported       (7),
       noSuchObject                 (32),
       invalidDNSyntax              (34),
       inappropriateAuthentication  (48),
       invalidCredentials           (49),
       busy                         (51),
       unavailable                  (52),
       unwillingToPerform           (53),
       other                        (80)

5.2.  Search

5.2.1.  Search Request

   The full LDAPv2 SearchRequest is defined in RFC 1777.

   An application providing a LDAP repository read service MUST
   implement the following subset of the SearchRequest.

      SearchRequest ::=
        [APPLICATION 3] SEQUENCE {
           baseObject     LDAPDN,
           scope             ENUMERATED {
                             baseObject   (0),
                                        },
           derefAliases   ENUMERATED {
                             neverDerefAliases   (0),
                                     },
           sizeLimit      INTEGER (0),
           timeLimit      INTEGER (0),
           attrsOnly      BOOLEAN, -- FALSE only
           filter         Filter,
           attributes     SEQUENCE OF AttributeType
                               }

      Filter ::=
        CHOICE {
          present        [7] AttributeType, -- "objectclass" only
                 }

   This subset of the LDAPv2 SearchRequest allows the LDAPv2 "read"
   operation: a base object search with a filter testing for the
   existence of the objectClass attribute.





Boeyen, et al.              Standards Track                     [Page 4]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


   An application providing a LDAP repository read service MAY implement
   other aspects of the SearchRequest as well.

5.2.2.

   The full LDAPv2 SearchResponse is defined in RFC 1777.

   An application providing a LDAP repository read service over LDAPv2
   MUST implement the full SearchResponse.

   Note that in the case of multivalued attributes such as
   userCertificate a SearchResponse containing this attribute will
   include all values, assuming the requester has sufficient access
   permissions.  The application/relying party may need to select an
   appropriate value to be used. Also note that retrieval of a
   certificate from a named entry does not guarantee that the
   certificate will include that same Distinguished Name (DN) and in
   some cases the subject DN in the certificate may be NULL.

5.3.  Unbind

   The full LDAPv2 UnbindRequest is defined in RFC 1777.

   An application providing a LDAP repository read service MUST
   implement the full UnbindRequest.

6.  LDAP Repository Search

   To search, using arbitrary criteria, for an entry in a repository
   containing a certificate, CRL, or other information of interest,
   requires a subset of the following three LDAP operations:

     BindRequest (and BindResponse)
     SearchRequest (and SearchResponse)
     UnbindRequest

   The subset of each operation REQUIRED is given below.

6.1.  Bind

   The BindRequest and BindResponse subsets needed are the same as those
   described in Section 5.1.

   The full LDAP v2 Bind Request is defined in RFC 1777.







Boeyen, et al.              Standards Track                     [Page 5]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


6.2.  Search

6.2.1.  Search Request

   The full LDAPv2 SearchRequest is defined in RFC 1777.

   An application providing a LDAP repository search service MUST
   implement the following subset of the SearchRequest protocol unit.

      SearchRequest ::=
        [APPLICATION 3] SEQUENCE {
           baseObject     LDAPDN,
           scope          ENUMERATED {
                               baseObject     (0),
                               singleLevel    (1),
                               wholeSubtree   (2)
                                     },
           derefAliases   ENUMERATED {
                               neverDerefAliases     (0),
                                     },
           sizeLimit      INTEGER (0 .. maxInt),
           timeLimit      INTEGER (0 .. maxInt),
           attrsOnly      BOOLEAN,  -- FALSE only
           filter         Filter,
           attributes     SEQUENCE OF AttributeType
                                }

   All aspects of the SearchRequest MUST be supported, except for the
   following:

   - Only the neverDerefAliases value of derefAliases needs to be
     supported

   - Only the FALSE value for attrsOnly needs to be supported

   This subset provides a more general search capability.  It is a
   superset of the SearchRequest subset defined in Section 5.2.1. The
   elements added to this service are:

   - singleLevel and wholeSubtree scope needs to be supported

   - sizeLimit is included

   - timeLimit is included

   - Enhanced filter capability





Boeyen, et al.              Standards Track                     [Page 6]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


   An application providing a LDAP repository search service MAY
   implement other aspects of the SearchRequest as well.

6.2.2.  Search Response

   The full LDAPv2 SearchResponse is defined in RFC 1777.

   An application providing a LDAP repository search service over LDAPv2
   MUST implement the full SearchResponse.

6.3.  Unbind

   An application providing a LDAP repository search service MUST
   implement the full UnbindRequest.

7.  LDAP Repository Modify

   To add, delete and modify PKI information in a repository  requires a
   subset of the following LDAP operations:

     BindRequest (and BindResponse)
     ModifyRequest (and ModifyResponse)
     AddRequest (and AddResponse)
     DelRequest (and DelResponse
     UnbindRequest

   The subset of each operation REQUIRED is given below.

7.1.  Bind

   The full LDAP v2 Bind Request is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the following subset of this operation:

      BindRequest ::=
        [APPLICATION 0] SEQUENCE {
           version      INTEGER (2),
           name         LDAPDN,
           simpleauth [0] OCTET STRING
           }

   A LDAP repository modify service MUST implement authenticated access.

   The BindResponse subsets needed are the same as those described in
   Section 5.1.2.





Boeyen, et al.              Standards Track                     [Page 7]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


7.2.  Modify

7.2.1.  Modify Request

   The full LDAPv2 ModifyRequest is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the following subset of the ModifyRequest protocol unit.

      ModifyRequest ::=
        [APPLICATION 6] SEQUENCE {
       object         LDAPDN,
       modification   SEQUENCE OF SEQUENCE {
                        operation     ENUMERATED {
                                        add     (0),
                                        delete  (1)
                                      },
                        modification  SEQUENCE {
                                      type   AttributeType,
                                      values SET OF
                                             AttributeValue
                                      }
                      }
        }

   All aspects of the ModifyRequest MUST be supported, except for the
   following:

   - Only the add and delete values of operation need to be supported

7.2.2.  Modify Response

   The full LDAPv2 ModifyResponse is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full ModifyResponse.

7.3.  Add

7.3.1.  Add Request

   The full LDAPv2 AddRequest is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full AddRequest.






Boeyen, et al.              Standards Track                     [Page 8]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


7.3.2.  Add Response

   The full LDAPv2 AddResponse is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full AddResponse.

7.4.  Delete

7.4.1.  Delete Request

   The full LDAPv2 DelRequest is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full DelRequest.

7.4.2.  Delete Response

   The full LDAPv2 DelResponse is defined in RFC 1777.

   An application providing a LDAP repository modify service MUST
   implement the full DelResponse.

7.5.  Unbind

   An application providing a LDAP repository modify service MUST
   implement the full UnbindRequest.

8.  Non-standard attribute value encodings

   When conveyed in LDAP requests and results, attributes defined in
   X.500 are to be encoded using string representations defined in RFC
   1778, The String Representation of Standard Attribute Syntaxes.
   These string encodings were based on the attribute definitions from
   X.500(1988).  Thus, the string representations of the PKI information
   elements are for version 1 certificates and version 1 revocation
   lists.  Since this specification uses version 3 certificates and
   version 2 revocation lists, as defined in X.509(1997), the RFC 1778
   string encoding of these attributes is inappropriate.

   For this reason, these attributes MUST be encoded using a syntax
   similar to the syntax "Undefined" from section 2.1 of RFC 1778:
   values of these attributes are encoded as if they were values of type
   "OCTET STRING", with the string value of the encoding being the DER-
   encoding of the value itself.  For example, when writing a
   userCertificate to the repository, the CA generates a DER-encoding of
   the certificate and uses that encoding as the value of the
   userCertificate attribute in the LDAP Modify request.This encoding



Boeyen, et al.              Standards Track                     [Page 9]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


   style is consistent with the encoding scheme proposed for LDAPv3,
   which is now being defined within the IETF.

   Note that certificates and revocation lists will be transferred using
   this mechanism rather than the string encodings in RFC 1778 and
   client systems which do not understand this encoding may experience
   problems with these attributes.

9.  Transport

   An application providing a LDAP repository read service, LDAP
   repository search service, or LDAP repository modify service MUST
   support LDAPv2 transport over TCP, as defined in Section 3.1 of RFC
   1777.

   An application providing a LDAP repository read service, LDAP
   repository search service, or LDAP repository modify service MAY
   support LDAPv2 transport over other reliable transports as well.

10.  Security Considerations

   Since the elements of information which are key to the PKI service
   (certificates and CRLs) are both digitally signed pieces of
   information, additional integrity service is NOT REQUIRED.  As
   neither information element need be kept secret and anonymous access
   to such information, for retrieval purposes is generally acceptable,
   privacy service is NOT REQUIRED for information retrieval requests.

   CAs have additional requirements, including modification of PKI
   information.  Simple authentication alone is not sufficient for these
   purposes. It is RECOMMENDED that some stronger means of
   authentication and/or (if simple authentication is used) some means
   of protecting the privacy of the password is used, (e.g.  accept
   modifications only via physically secure networks, use IPsec, use SSH
   or TLS or SSL tunnel). Without such authentication, it is possible
   that a denial-of-service attack could occur where the attacker
   replaces valid certificates with bogus ones.

   For the LDAP repository modify service, profiled in section 7, there
   are some specific security considerations with respect to access
   control. These controls apply to a repository which is under the same
   management control as the CA. Organizations operating directories are
   NOT REQUIRED to provide external CAs access permission to their
   directories.







Boeyen, et al.              Standards Track                    [Page 10]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


   The CA MUST have access control permissions allowing it to:

      For CA entries:
         - add, modify and delete all PKI attributes for its own
           directory entry;
         - add, modify and delete all values of these attributes.

      For CRL distribution point entries (if used):
         - create, modify and delete entries of object class
           cRLDistributionPoint immediately subordinate to its own
           entry;
         - add, modify and delete all attributes, and all values of
           these attributes for these entries.

      For subscriber (end-entity) entries:
         - add, modify and delete the attribute userCertificate and all
           values of that attribute, issued by this CA to/from these
           entries.

   The CA is the ONLY entity with these permissions.

   An application providing LDAP repository read, LDAP repository
   search, or LDAP repository modify service as defined in this
   specification is NOT REQUIRED to implement any additional security
   features other than those described herein, however an implementation
   SHOULD do so.

11.  References

   [1]  Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
        Protocol", RFC 1777, March 1995.

   [2]  Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String
        Representation of Standard Attribute Syntaxes", RFC 1778, March
        1995.

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













Boeyen, et al.              Standards Track                    [Page 11]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


12.  Authors' Addresses

   Sharon Boeyen
   Entrust Technologies Limited
   750 Heron Road
   Ottawa, Ontario
   Canada K1V 1A7

   EMail: sharon.boeyen@entrust.com


   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043
   USA

   EMail: howes@netscape.com


   Patrick Richard
   Xcert Software Inc.
   Suite 1001, 701 W. Georgia Street
   P.O. Box 10145
   Pacific Centre
   Vancouver, B.C.
   Canada V7Y 1C6

   EMail: patr@xcert.com






















Boeyen, et al.              Standards Track                    [Page 12]

RFC 2559          PKIX Operational Protocols - LDAPv2         April 1999


13.  Full Copyright Statement

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
























Boeyen, et al.              Standards Track                    [Page 13]