idnits 2.17.1 draft-zeilenga-ldap-x509-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 27. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1098. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1069. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1082. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1086), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 44. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 42 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2252, but the abstract doesn't seem to directly say this. It does mention RFC2252 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2256, but the abstract doesn't seem to directly say this. It does mention RFC2256 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 912 has weird spacing: '...ubtrees msp G...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (18 July 2005) is 6829 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1777' is mentioned on line 82, but not defined ** Obsolete undefined reference: RFC 1777 (Obsoleted by RFC 3494) == Missing Reference: 'RFC3494' is mentioned on line 82, but not defined == Missing Reference: 'RFC3342' is mentioned on line 678, but not defined == Missing Reference: 'RFC3786' is mentioned on line 793, but not defined ** Obsolete undefined reference: RFC 3786 (Obsoleted by RFC 5311) == Unused Reference: 'RFC3383' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'RFC3642' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'BCP64bis' is defined on line 668, but no explicit reference was found in the text -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-legg-ldap-binary-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Binary' -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 3280 (Obsoleted by RFC 5280) -- Obsolete informational reference (is this intentional?): RFC 3383 (Obsoleted by RFC 4520) -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 12 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 18 July 2005 5 Obsoletes: RFC 2252, RFC 2256, RFC 2587 7 Lightweight Directory Access Protocol (LDAP) schema 8 definitions for X.509 Certificates 9 11 Status of this Memo 13 This document is intended to be, after appropriate review and 14 revision, submitted to the RFC Editor as an Standard Track document. 15 Distribution of this memo is unlimited. Technical discussion of this 16 document will take place on the IETF LDAP Extensions mailing list 17 . Please send editorial comments directly to the 18 author . 20 This document is intended to be published in conjunction to the 21 revised LDAP TS [Roadmap]. Together, this document and the revised 22 LDAP TS obsoletes RFC 2252 and RFC 2256 in their entirety. 24 By submitting this Internet-Draft, each author represents that any 25 applicable patent or other IPR claims of which he or she is aware have 26 been or will be disclosed, and any of which he or she becomes aware 27 will be disclosed, in accordance with Section 6 of BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering Task 30 Force (IETF), its areas, and its working groups. Note that other 31 groups may also distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference material 36 or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright (C) The Internet Society (2005). All Rights Reserved. 46 Please see the Full Copyright section near the end of this document 47 for more information. 49 Abstract 51 This document describes schema for representing X.509 certificates, 52 X.521 security information, and related elements in directories 53 accessible using the Lightweight Directory Access Protocol (LDAP). 54 The LDAP definitions for these X.509 and X.521 schema elements 55 replaces those provided in RFC 2252 and RFC 2256. 57 1. Background and Intended Use 59 This document provides LDAP [Roadmap] schema definitions [Models] for 60 a subset of elements specified in X.509 [X.509] and X.521 [X.521], 61 including attribute types for certificates, cross certificate pairs, 62 and certificate revocation lists; matching rules to be used with these 63 attribute types; and related object classes. LDAP syntax definitions 64 are also provided for associated assertion and attribute values. 66 As the semantics of these elements are as defined in X.509 and X.521, 67 knowledge of X.509 and X.521 is necessary to make use of the LDAP 68 schema definitions provided herein. 70 This document, together with [Roadmap], obsoletes RFC 2252 and RFC 71 2256 in their entirety. The changes (in this document) made since RFC 72 2252 and RFC 2256 include: 73 - addition of pkiUser, pkiCA, and deltaCRL classes; 74 - update of attribute types to include equality matching rules in 75 accordance with their X.500 specifications; 76 - addition of certificate, certificate pair, certificate list, and 77 algorithm identifer matching rules; and 78 - addition of LDAP syntax for assertion syntaxes for these matching 79 rules. 81 This document obsoletes RFC 2587. The X.509 schema descriptions for 82 LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494]. 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in BCP 14 [RFC2119]. 88 Schema definitions are provided using LDAP description formats 89 [Models]. Definitions provided here are formatted (line wrapped) for 90 readability. 92 2. Syntaxes 94 This section describes various syntaxes used in LDAP to transfer 95 certificates and related data types. 97 2.1. Certificate 99 ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' ) 101 A value of this syntax is an X.509 Certificate [X.509, clause 7]. 103 Due to changes made to the definition of a Certificate made through 104 time, no LDAP-specific encoding is defined for this syntax. Values of 105 this syntax SHOULD be encoded using Distinguished Encoding Rules (DER) 106 [X.690] and MUST only be transferred using the ;binary transfer option 107 [Binary]. That is, by requesting and returning values using attribute 108 descriptions such as "userCertificate;binary". 110 As values of this syntax contain digitally-signed data, values of this 111 syntax, and the form of the value, MUST be preserved as presented. 113 2.2. CertificateList 115 ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' ) 117 A value of this syntax is an X.509 CertificateList [X.509, clause 118 7.3]. 120 Due to changes made to the definition of a CertificateList made 121 through time, no LDAP-specific encoding is defined for this syntax. 122 Values of this syntax SHOULD be encoded using DER [X.690] and MUST 123 only be transferred using the ;binary transfer option [Binary]. That 124 is, by requesting and returning values using attribute descriptions 125 such as "certificateRevocationList;binary". 127 As values of this syntax contain digitally-signed data, values of this 128 syntax, and the form of the value, MUST be preserved as presented. 130 2.3. CertificatePair 132 ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' ) 134 A value of this syntax is an X.509 CertificatePair [X.509, clause 135 11.2.3]. 137 Due to changes made to the definition of an X.509 CertificatePair made 138 through time, no LDAP-specific encoding is defined for this syntax. 139 Values of this syntax SHOULD be encoded using DER [X.690] and MUST 140 only be transferred using the ;binary transfer option [Binary]. That 141 is, by requesting and returning values using attribute descriptions 142 such as "crossCertificatePair;binary". 144 As values of this syntax contain digitally-signed data, values of this 145 syntax, and the form of the value, MUST be preserved as presented. 147 2.4 SupportedAlgorithm 149 ( 1.3.6.1.4.1.1466.115.121.1.49 150 DESC 'X.509 Supported Algorithm' ) 152 A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause 153 11.2.7]. 155 Due to changes made to the definition of an X.509 SupportedAlgorithm 156 made through time, no LDAP-specific encoding is defined for this 157 syntax. Values of this syntax SHOULD be encoded using DER [X.690] and 158 MUST only be transferred using the ;binary transfer option [Binary]. 159 That is, by requesting and returning values using attribute 160 descriptions such as "supportedAlgorithms;binary". 162 As values of this syntax contain digitally-signed data, values of this 163 syntax, and the form of the value, MUST be preserved as presented. 165 2.5. CertificateExactAssertion 167 ( IANA-ASSIGNED-OID.1 DESC 'X.509 Certificate Exact Assertion' ) 169 A value of this syntax is an X.509 CertificateExactAssertion [X.509, 170 clause 11.3.1]. Values of this syntax MUST be encoded using the 171 Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1 provides 172 an equivalent Augmented Backus-Naur Form (ABNF) [ABNF] grammar for 173 this syntax. 175 2.6. CertificateAssertion 177 ( IANA-ASSIGNED-OID.2 DESC 'X.509 Certificate Assertion' ) 179 A value of this syntax is an X.509 CertificateAssertion [X.509, clause 180 11.3.2]. Values of this syntax MUST be encoded using GSER [RFC3641]. 181 Appendix A.2 provides an equivalent ABNF [ABNF] grammar for this 182 syntax. 184 2.7. CertificatePairExactAssertion 186 ( IANA-ASSIGNED-OID.3 187 DESC 'X.509 Certificate Pair Exact Assertion' ) 189 A value of this syntax is an X.509 CertificatePairExactAssertion 190 [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using 191 GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [ABNF] 192 grammar for this syntax. 194 2.8. CertificatePairAssertion 196 ( IANA-ASSIGNED-OID.4 DESC 'X.509 Certificate Pair Assertion' ) 198 A value of this syntax is an X.509 CertificatePairAssertion [X.509, 199 clause 11.3.4]. Values of this syntax MUST be encoded using GSER 200 [RFC3641]. Appendix A.4 provides an equivalent ABNF [ABNF] grammar 201 for this syntax. 203 2.9. CertificateListExactAssertion 205 ( IANA-ASSIGNED-OID.5 206 DESC 'X.509 Certificate List Exact Assertion' ) 208 A value of this syntax is an X.509 CertificateListExactAssertion 209 [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using 210 GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for 211 this syntax. 213 2.10. CertificateListAssertion 215 ( IANA-ASSIGNED-OID.6 DESC 'X.509 Certificate List Assertion' ) 217 A value of this syntax is an X.509 CertificateListAssertion [X.509, 218 clause 11.3.6]. Values of this syntax MUST be encoded using GSER 219 [RFC3641]. Appendix A.6 provides an equivalent ABNF [ABNF] grammar 220 for this syntax. 222 2.11 AlgorithmIdentifier 224 ( IANA-ASSIGNED-OID.7 DESC 'X.509 Algorithm Identifier' ) 226 A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause 227 7]. Values of this syntax MUST be encoded using GSER [RFC3641]. 229 Appendix A.7 provides an equivalent ABNF [ABNF] grammar for this 230 syntax. 232 3. Matching Rules 234 This section introduces a set of certificate and related matching 235 rules for use in LDAP. These rules are intended to act in accordance 236 with their X.500 counterparts. 238 3.1. certificateExactMatch 240 The certificateExactMatch matching rule compares the presented 241 certificate exact assertion value with an attribute value of the 242 certificate syntax as described in clause 11.3.1 of [X.509]. 244 ( 2.5.13.34 NAME 'certificateExactMatch' 245 DESC 'X.509 Certificate Exact Match' 246 SYNTAX IANA-ASSIGNED-OID.1 ) 248 3.2. certificateMatch 250 The certificateMatch matching rule compares the presented certificate 251 assertion value with an attribute value of the certificate syntax as 252 described in clause 11.3.2 of [X.509]. 254 ( 2.5.13.35 NAME 'certificateMatch' 255 DESC 'X.509 Certificate Match' 256 SYNTAX IANA-ASSIGNED-OID.2 ) 258 3.3. certificatePairExactMatch 260 The certificatePairExactMatch matching rule compares the presented 261 certificate pair exact assertion value with an attribute value of the 262 certificate pair syntax as described in clause 11.3.3 of [X.509]. 264 ( 2.5.13.36 NAME 'certificatePairExactMatch' 265 DESC 'X.509 Certificate Pair Exact Match' 266 SYNTAX IANA-ASSIGNED-OID.3 ) 268 3.4. certificatePairMatch 270 The certificatePairMatch matching rule compares the presented 271 certificate pair assertion value with an attribute value of the 272 certificate pair syntax as described in clause 11.3.4 of [X.509]. 274 ( 2.5.13.37 NAME 'certificatePairMatch' 275 DESC 'X.509 Certificate Pair Match' 276 SYNTAX IANA-ASSIGNED-OID.4 ) 278 3.5. certificateListExactMatch 280 The certificateListExactMatch matching rule compares the presented 281 certificate list exact assertion value with an attribute value of the 282 certificate pair syntax as described in clause 11.3.5 of [X.509]. 284 ( 2.5.13.38 NAME 'certificateListExactMatch' 285 DESC 'X.509 Certificate List Exact Match' 286 SYNTAX IANA-ASSIGNED-OID.5 ) 288 3.6. certificateListMatch 290 The certificateListMatch matching rule compares the presented 291 certificate list assertion value with an attribute value of the 292 certificate pair syntax as described in clause 11.3.6 of [X.509]. 294 ( 2.5.13.39 NAME 'certificateListMatch' 295 DESC 'X.509 Certificate List Match' 296 SYNTAX IANA-ASSIGNED-OID.6 ) 298 3.7. algorithmIdentifierMatch 300 The algorithmIdentifierMatch mating rule compares a presented 301 algorithm identifier with an attribute value of supported algorithm as 302 described in clause 11.3.7 of [X.509]. 304 ( 2.5.13.40 NAME 'algorithmIdentifier' 305 DESC 'X.509 Algorithm Identifier Match' 306 SYNTAX IANA-ASSIGNED-OID.7 ) 308 4. Attribute Types 310 This section details a set of certificate and related attribute types 311 for use in LDAP. 313 4.1. userCertificate 314 The userCertificate attribute holds the X.509 certificates issued to 315 the user by one or more certificate authorities, as discussed in 316 clause 11.2.1 of [X.509]. 318 ( 2.5.4.36 NAME 'userCertificate' 319 DESC 'X.509 user certificate' 320 EQUALITY certificateExactMatch 321 SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) 323 As required by this attribute type's syntax, values of this attribute 324 are requested and transferred using the attribute description 325 "userCertificate;binary". 327 4.2. cACertificate 329 The cACertificate attribute holds the X.509 certificates issued to the 330 certificate authority (CA), as discussed in clause 11.2.2 of [X.509]. 332 ( 2.5.4.37 NAME 'cACertificate' 333 DESC 'X.509 CA certificate' 334 EQUALITY certificateExactMatch 335 SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) 337 As required by this attribute type's syntax, values of this attribute 338 are requested and transferred using the attribute description 339 "cACertificate;binary". 341 4.3. crossCertificatePair 343 The crossCertificatePair attribute holds an X.509 certificate pair, as 344 discussed in clause 11.2.3 of [X.509]. 346 ( 2.5.4.40 NAME 'crossCertificatePair' 347 DESC 'X.509 cross certificate pair' 348 EQUALITY certificatePairExactMatch 349 SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 ) 351 As required by this attribute type's syntax, values of this attribute 352 are requested and transferred using the attribute description 353 "crossCertificatePair;binary". 355 4.4. certificateRevocationList 357 The certificateRevocationList attribute holds certificate lists, as 358 discussed in 11.2.4 of [X.509]. 360 ( 2.5.4.39 NAME 'certificateRevocationList' 361 DESC 'X.509 certificate revocation list' 362 EQUALITY certificateListExactMatch 363 SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) 365 As required by this attribute type's syntax, values of this attribute 366 are requested and transferred using the attribute description 367 "certificateRevocationList;binary". 369 4.5. authorityRevocationList 371 The authorityRevocationList attribute holds certificate lists, as 372 discussed in 11.2.5 of [X.509]. 374 ( 2.5.4.38 NAME 'authorityRevocationList' 375 DESC 'X.509 authority revocation list' 376 EQUALITY certificateListExactMatch 377 SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) 379 As required by this attribute type's syntax, values of this attribute 380 are requested and transferred using the attribute description 381 "authorityRevocationList;binary". 383 4.6. deltaRevocationList 385 The deltaRevocationList attribute holds certificate lists, as 386 discussed in 11.2.6 of [X.509]. 388 ( 2.5.4.53 NAME 'deltaRevocationList' 389 DESC 'X.509 delta revocation list' 390 EQUALITY certificateListExactMatch 391 SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) 393 As required by this attribute type's syntax, values of this attribute 394 MUST be requested and transferred using the attribute description 395 "deltaRevocationList;binary". 397 4.7. supportedAlgorithms 399 The supportedAlgorithms attribute holds supported algorithms, as 400 discussed in 11.2.7 of [X.509]. 402 ( 2.5.4.52 NAME 'supportedAlgorithms' 403 DESC 'X.509 supported algorithms' 404 EQUALITY algorithmIdentifierMatch 405 SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 ) 407 As required by this attribute type's syntax, values of this attribute 408 MUST be requested and transferred using the attribute description 409 "supportedAlgorithms;binary". 411 5. Object Classes 413 This section details a set of certificate-related object classes for 414 use in LDAP. 416 5.1. pkiUser 418 This object class is used in augment entries for objects that may be 419 subject to certificates, as defined in clause 11.1.1 of [X.509]. 421 ( 2.5.6.21 NAME 'pkiUser' 422 DESC 'X.509 PKI User' 423 SUP top AUXILIARY 424 MAY userCertificate ) 426 5.2. pkiCA 428 This object class is used to augment entries for objects which act as 429 certificate authorities, as defined in clause 11.1.2 of [X.509] 431 ( 2.5.6.22 NAME 'pkiCA' 432 DESC 'X.509 PKI Certificate Authority' 433 SUP top AUXILIARY 434 MAY ( cACertificate $ certificateRevocationList $ 435 authorityRevocationList $ crossCertificatePair ) ) 437 5.3. cRLDistributionPoint 439 This class is used to represent objects which act as CRL distribution 440 points, as discussed in clause 11.1.3 of [X.509]. 442 ( 2.5.6.19 NAME 'cRLDistributionPoint' 443 DESC 'X.509 CRL distribution point' 444 SUP top STRUCTURAL 445 MUST cn 446 MAY ( certificateRevocationList $ 447 authorityRevocationList $ deltaRevocationList ) ) 449 5.4 deltaCRL 451 The deltaCRL object class is used to augment entries to hold delta 452 revocation lists, as discussed in clause 11.1.4 of [X.509]. 454 ( 2.5.6.23 NAME 'deltaCRL' 455 DESC 'X.509 delta CRL' 456 SUP top AUXILIARY 457 MAY deltaRevocationList ) 459 5.5. strongAuthenticationUser 461 This object class is used to augment entries for objects participating 462 in certificate-based authentication, as defined in clause 6.15 of 463 [X.521]. This object class is deprecated in favor of pkiUser. 465 ( 2.5.6.15 NAME 'strongAuthenticationUser' 466 DESC 'X.521 strong authentication user' 467 SUP top AUXILIARY 468 MUST userCertificate ) 470 5.6. userSecurityInformation 472 This object class is used to augment entries with needed additional 473 associated security information, as defined in clause 6.16 of [X.521]. 475 ( 2.5.6.18 NAME 'userSecurityInformation' 476 DESC 'X.521 user security information' 477 SUP top AUXILIARY 478 MAY ( supportedAlgorithms ) ) 480 5.7. certificationAuthority 482 This object class is used to augment entries for objects which act as 483 certificate authorities, as defined in clause 6.17 of [X.521]. This 484 object class is deprecated in favor of pkiCA. 486 ( 2.5.6.16 NAME 'certificationAuthority' 487 DESC 'X.509 certificate authority' 488 SUP top AUXILIARY 489 MUST ( authorityRevocationList $ 490 certificateRevocationList $ cACertificate ) 491 MAY crossCertificatePair ) 493 5.8. certificationAuthority-V2 495 This object class is used to augment entries for objects which act as 496 certificate authorities, as defined in clause 6.18 of [X.521]. This 497 object class is deprecated in favor of pkiCA. 499 ( 2.5.6.16.2 NAME 'certificationAuthority-V2' 500 DESC 'X.509 certificate authority, version 2' 501 SUP certificationAuthority AUXILIARY 502 MAY deltaRevocationList ) 504 6. Security Considerations 506 General certificate considerations [RFC3280] apply to LDAP-aware 507 certificate applications. General LDAP security considerations 508 [Roadmap] apply as well. 510 While elements of certificate information are commonly signed, these 511 signatures only protect the integrity of the signed information. In 512 the absence of a data integrity protections in LDAP (or lower layer, 513 e.g. IPsec), a server is not assured that client certificate request 514 (or other request) was unaltered in transit. Likewise, a client 515 cannot be assured that the results of the query were unaltered in 516 transit. Hence, it is generally recommended implementations make use 517 of authentication and data integrity services in LDAP 518 [AuthMeth][Protocol]. 520 7. IANA Considerations 522 7.1. Object Identifier Registration 524 It is requested that IANA register upon Standards Action an LDAP 525 Object Identifier for use in this technical specification. 527 Subject: Request for LDAP OID Registration 528 Person & email address to contact for further information: 529 Kurt Zeilenga 530 Specification: RFC XXXX 531 Author/Change Controller: IESG 532 Comments: 533 Identifies the LDAP X.509 Certificate schema elements 534 introduced in this document. 536 7.2. Registration of the descriptor 537 It is requested that IANA update upon Standards Action the LDAP 538 Descriptor registry as indicated below. 540 Subject: Request for LDAP Descriptor Registration 541 Descriptor (short name): see table 542 Object Identifier: see table 543 Person & email address to contact for further information: 544 Kurt Zeilenga 545 Usage: see table 546 Specification: RFC XXXX 547 Author/Change Controller: IESG 549 algorithmIdentifierMatch R 2.5.13.40 550 authorityRevocationList A 2.5.4.38 * 551 cACertificate A 2.5.4.37 * 552 cRLDistributionPoint O 2.5.6.19 * 553 certificateExactMatch R 2.5.13.34 554 certificateListExactMatch R 2.5.13.38 555 certificateListMatch R 2.5.13.39 556 certificateMatch R 2.5.13.35 557 certificatePairExactMatch R 2.5.13.36 558 certificatePairMatch R 2.5.13.37 559 certificateRevocationList A 2.5.4.39 * 560 certificationAuthority O 2.5.6.16 * 561 certificationAuthority-V2 O 2.5.6.16.2 * 562 crossCertificatePair A 2.5.4.40 * 563 deltaCRL O 2.5.6.23 * 564 deltaRevocationList A 2.5.4.53 * 565 pkiCA O 2.5.6.22 * 566 pkiUser O 2.5.6.21 * 567 strongAuthenticationUser O 2.5.6.15 * 568 supportedAlgorithms A 2.5.4.52 * 569 userCertificate A 2.5.4.36 * 570 userSecurityInformation O 2.5.6.18 * 572 * Updates previous registration 574 8. Acknowledgments 576 This document is based upon X.509, a product of the ITU-T. A number 577 of LDAP schema definitions were based on those found in RFC 2252 and 578 RFC 2256, both products of the IETF ASID WG. The ABNF productions in 579 Appendix A were provided by Steven Legg. Additional material was 580 borrowed from prior works by David Chadwick and Steven Legg to refine 581 the LDAP X.509 schema. 583 9. Author's Address 585 Kurt D. Zeilenga 586 OpenLDAP Foundation 588 Email: Kurt@OpenLDAP.org 590 10. References 592 [[Note to the RFC Editor: please replace the citation tags used in 593 referencing Internet-Drafts with tags of the form RFCnnnn where 594 possible.]] 596 10.1. Normative References 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 601 [RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1 602 Types", RFC 3641, October 2003. 604 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 605 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 606 progress. 608 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 609 Models", draft-ietf-ldapbis-models-xx.txt, a work in 610 progress. 612 [Binary] Legg, S., "Lightweight Directory Access Protocol (LDAP): 613 The Binary Encoding Option", 614 draft-legg-ldap-binary-xx.txt, a work in progress. 616 [X.509] International Telecommunication Union - 617 Telecommunication Standardization Sector, "The 618 Directory: Authentication Framework", X.509(2000). 620 [X.521] International Telecommunication Union - 621 Telecommunication Standardization Sector, "The 622 Directory: Selected Object Classes", X.521(2000). 624 [X.680] International Telecommunication Union - 625 Telecommunication Standardization Sector, "Abstract 626 Syntax Notation One (ASN.1) - Specification of Basic 627 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 629 [X.690] International Telecommunication Union - 630 Telecommunication Standardization Sector, "Specification 631 of ASN.1 encoding rules: Basic Encoding Rules (BER), 632 Canonical Encoding Rules (CER), and Distinguished 633 Encoding Rules (DER)", X.690(2002) (also ISO/IEC 634 8825-1:2002). 636 11.2. Informative References 638 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 639 Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a 640 work in progress. 642 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 643 Connection Level Security Mechanisms", 644 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 646 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 647 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 649 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): 650 Mapping between X.400 and RFC 822/MIME", RFC 2156, 651 January 1998. 653 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 654 X.509 Public Key Infrastructure Certificate and 655 Certificate Revocation List (CRL) Profile", RFC 3280, 656 April 2002. 658 [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64 659 (also RFC 3383), September 2002. 661 [RFC3642] Legg, S., "Common Elements of GSER Encodings", RFC 3642, 662 October 2003. 664 [RFC3687] Legg, S., "Lightweight Directory Access Protocol (LDAP) 665 and X.500 Component Matching Rules", RFC 3687, February 666 2004. 668 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 669 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 671 Appendix A. 673 This appendix is informative. 675 This appendix provides ABNF [ABNF] grammars for GSER-based [RFC3687] 676 LDAP-specific encodings specified in this document. These grammars 677 where produced using, and relying on, Common Elements for GSER 678 Encodings [RFC3342]. 680 A.1. CertificateExactAssertion 682 CertificateExactAssertion = "{" sp cea-serialNumber "," 683 sp cea-issuer sp "}" 685 cea-serialNumber = id-serialNumber msp CertificateSerialNumber 686 cea-issuer = id-issuer msp Name 688 id-serialNumber = 689 %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber' 690 id-issuer = %x69.73.73.75.65.72 ; 'issuer' 692 Name = id-rdnSequence ":" RDNSequence 693 id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence' 695 CertificateSerialNumber = INTEGER 697 A.2. CertificateAssertion 699 CertificateAssertion = "{" [ sp ca-serialNumber ] 700 [ sep sp ca-issuer ] 701 [ sep sp ca-subjectKeyIdentifier ] 702 [ sep sp ca-authorityKeyIdentifier ] 703 [ sep sp ca-certificateValid ] 704 [ sep sp ca-privateKeyValid ] 705 [ sep sp ca-subjectPublicKeyAlgID ] 706 [ sep sp ca-keyUsage ] 707 [ sep sp ca-subjectAltName ] 708 [ sep sp ca-policy ] 709 [ sep sp ca-pathToName ] 710 [ sep sp ca-subject ] 711 [ sep sp ca-nameConstraints ] sp "}" 713 ca-serialNumber = id-serialNumber msp CertificateSerialNumber 714 ca-issuer = id-issuer msp Name 715 ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp 716 SubjectKeyIdentifier 717 ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp 718 AuthorityKeyIdentifier 719 ca-certificateValid = certificateValid msp Time 720 ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime 721 ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp 722 OBJECT-IDENTIFIER 723 ca-keyUsage = id-keyUsage msp KeyUsage 724 ca-subjectAltName = id-subjectAltName msp AltNameType 725 ca-policy = id-policy msp CertPolicySet 726 ca-pathToName = id-pathToName msp Name 727 ca-subject = id-subject msp Name 728 ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax 730 id-subjectKeyIdentifier = 731 %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72 732 ; 'subjectKeyIdentifier' 733 id-authorityKeyIdentifier = 734 %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72 735 ; 'authorityKeyIdentifier' 736 id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64 737 ; 'certificateValid' 738 id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64 739 ; 'privateKeyValid' 740 id-subjectPublicKeyAlgID = 741 %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44 742 ; 'subjectPublicKeyAlgID' 743 id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage' 744 id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65 745 ; 'subjectAltName' 746 id-policy = %x70.6F.6C.69.63.79 ; 'policy' 747 id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName' 748 id-subject = %x73.75.62.6A.65.63.74 ; 'subject' 749 id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73 750 ; 'nameConstraints' 752 SubjectKeyIdentifier = KeyIdentifier 754 KeyIdentifier = OCTET-STRING 756 AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ] 757 [ sep sp aki-authorityCertIssuer ] 758 [ sep sp aki-authorityCertSerialNumber ] sp "}" 760 aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier 761 aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames 763 GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}" 764 GeneralName = gn-otherName 765 / gn-rfc822Name 766 / gn-dNSName 767 / gn-x400Address 768 / gn-directoryName 769 / gn-ediPartyName 770 / gn-uniformResourceIdentifier 771 / gn-iPAddress 772 / gn-registeredID 774 gn-otherName = id-otherName ":" OtherName 775 gn-rfc822Name = id-rfc822Name ":" IA5String 776 gn-dNSName = id-dNSName ":" IA5String 777 gn-x400Address = id-x400Address ":" ORAddress 778 gn-directoryName = id-directoryName ":" Name 779 gn-ediPartyName = id-ediPartyName ":" EDIPartyName 780 gn-iPAddress = id-iPAddress ":" OCTET-STRING 781 gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER 783 gn-uniformResourceIdentifier = id-uniformResourceIdentifier 784 ":" IA5String 786 id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName' 787 gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44 788 ; 'registeredID' 790 OtherName = "{" sp on-type-id "," sp on-value sp "}" 791 on-type-id = id-type-id msp OBJECT-IDENTIFIER 792 on-value = id-value msp Value 793 ;; as defined in Section 8 of [RFC3786] 795 id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id' 796 id-value = %x76.61.6C.75.65 ; 'value' 798 ORAddress = dquote *SafeIA5Character dquote 799 SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote 800 dquote dquote ; escaped double quote 801 dquote = %x22 ; '"' (double quote) 803 ;; Note: The rule encodes the x400Address component 804 ;; of a GeneralName as a character string between double quotes. 805 ;; The character string is first derived according to Section 4.1 806 ;; of [RFC2156], and then any embedded double quotes are escaped 807 ;; by being repeated. This resulting string is output between 808 ;; double quotes. 810 EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}" 811 nameAssigner = id-nameAssigner msp DirectoryString 812 partyName = id-partyName msp DirectoryString 813 id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72 814 ; 'nameAssigner' 815 id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName' 816 aki-authorityCertSerialNumber = id-authorityCertSerialNumber 817 msp CertificateSerialNumber 819 id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72 820 ; 'keyIdentifier' 821 id-authorityCertIssuer = 822 %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72 823 ; 'authorityCertIssuer' 825 id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43 826 %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72 827 ; 'authorityCertSerialNumber' 829 Time = time-utcTime / time-generalizedTime 830 time-utcTime = id-utcTime ":" UTCTime 831 time-generalizedTime = id-generalizedTime ":" GeneralizedTime 832 id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime' 833 id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65 834 ; 'generalizedTime' 836 KeyUsage = BIT-STRING / key-usage-bit-list 837 key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}" 839 ;; Note: The rule encodes the one bits in 840 ;; a KeyUsage value as a comma separated list of identifiers. 842 key-usage = id-digitalSignature 843 / id-nonRepudiation 844 / id-keyEncipherment 845 / id-dataEncipherment 846 / id-keyAgreement 847 / id-keyCertSign 848 / id-cRLSign 849 / id-encipherOnly 850 / id-decipherOnly 852 id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74 853 %x75.72.65 ; 'digitalSignature' 854 id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E 855 ; 'nonRepudiation' 856 id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74 857 ; 'keyEncipherment' 858 id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E 859 %x74 ; "dataEncipherment' 860 id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74 861 ; 'keyAgreement' 862 id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E 863 ; 'keyCertSign' 865 id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign" 866 id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79 867 ; 'encipherOnly' 868 id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79 869 ; 'decipherOnly' 871 AltNameType = ant-builtinNameForm / ant-otherNameForm 873 ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm 874 ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER 876 id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D 877 ; 'builtinNameForm' 878 id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D 879 ; 'otherNameForm' 881 BuiltinNameForm = id-rfc822Name 882 / id-dNSName 883 / id-x400Address 884 / id-directoryName 885 / id-ediPartyName 886 / id-uniformResourceIdentifier 887 / id-iPAddress 888 / id-registeredId 890 id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name' 891 id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName' 892 id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address' 893 id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65 894 ; 'directoryName' 895 id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65 896 ; 'ediPartyName' 897 id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress' 898 id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64 899 ; 'registeredId' 901 id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75 902 %x72.63.65.49.64.65.6E.74.69.66.69.65.72 903 ; 'uniformResourceIdentifier' 905 CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}" 906 CertPolicyId = OBJECT-IDENTIFIER 908 NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ] 909 [ sep sp ncs-excludedSubtrees ] sp "}" 911 ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees 912 ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees 913 id-permittedSubtrees = 914 %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73 915 ; 'permittedSubtrees' 916 id-excludedSubtrees = 917 %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73 918 ; 'excludedSubtrees' 920 GeneralSubtrees = "{" sp GeneralSubtree 921 *( "," sp GeneralSubtree ) sp "}" 922 GeneralSubtree = "{" sp gs-base 923 [ "," sp gs-minimum ] 924 [ "," sp gs-maximum ] sp "}" 926 gs-base = id-base msp GeneralName 927 gs-minimum = id-minimum msp BaseDistance 928 gs-maximum = id-maximum msp BaseDistance 930 id-base = %x62.61.73.65 ; 'base' 931 id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum' 932 id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum' 934 BaseDistance = INTEGER-0-MAX 936 A.3. CertificatePairExactAssertion 938 CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ] 939 [sep sp cpea-issuedBy ] sp "}" 940 ;; At least one of or MUST be present. 942 cpea-issuedTo = id-issuedToThisCAAssertion msp 943 CertificateExactAssertion 944 cpea-issuedBy = id-issuedByThisCAAssertion msp 945 CertificateExactAssertion 947 id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73 948 %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion' 949 id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73 950 %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion' 952 A.4. CertificatePairAssertion 954 CertificatePairAssertion = "{" [ sp cpa-issuedTo ] 955 [sep sp cpa-issuedBy ] sp "}" 956 ;; At least one of and MUST be present. 958 cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion 959 cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion 961 A.5. CertificateListExactAssertion 963 CertificateListExactAssertion = "{" sp clea-issuer "," 964 sp clea-thisUpdate 965 [ "," sp clea-distributionPoint ] sp "}" 967 clea-issuer = id-issuer msp Name 968 clea-thisUpdate = id-thisUpdate msp Time 969 clea-distributionPoint = id-distributionPoint msp 970 DistributionPointName 972 id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate' 973 id-distributionPoint = 974 %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74 975 ; 'distributionPoint' 977 DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer 979 dpn-fullName = id-fullName ":" GeneralNames 980 dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":" 981 RelativeDistinguishedName 983 id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName' 984 id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65 985 %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer' 987 A.6. CertificateListAssertion 989 CertificateListAssertion = "{" [ sp cla-issuer ] 990 [ sep sp cla-minCRLNumber ] 991 [ sep sp cla-maxCRLNumber ] 992 [ sep sp cla-reasonFlags ] 993 [ sep sp cla-dateAndTime ] 994 [ sep sp cla-distributionPoint ] 995 [ sep sp cla-authorityKeyIdentifier ] sp "}" 997 cla-issuer = id-issuer msp Name 998 cla-minCRLNumber = id-minCRLNumber msp CRLNumber 999 cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber 1000 cla-reasonFlags = id-reasonFlags msp ReasonFlags 1001 cla-dateAndTime = id-dateAndTime msp Time 1003 cla-distributionPoint = id-distributionPoint msp 1004 DistributionPointName 1006 cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp 1007 AuthorityKeyIdentifier 1009 id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72 1010 ; 'minCRLNumber' 1011 id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72 1012 ; 'maxCRLNumber' 1013 id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags' 1014 id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime' 1016 CRLNumber = INTEGER-0-MAX 1018 ReasonFlags = BIT-STRING 1019 / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}" 1021 reason-flag = id-unused 1022 / id-keyCompromise 1023 / id-cACompromise 1024 / id-affiliationChanged 1025 / id-superseded 1026 / id-cessationOfOperation 1027 / id-certificateHold 1028 / id-privilegeWithdrawn 1029 / id-aACompromise 1031 id-unused = %x75.6E.75.73.65.64 ; 'unused' 1032 id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65 1033 ; 'keyCompromise' 1034 id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65 1035 ; 'cACompromise' 1036 id-affiliationChanged = 1037 %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64 1038 ; 'affiliationChanged' 1039 id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded' 1040 id-cessationOfOperation = 1041 %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E 1042 ; 'cessationOfOperation' 1043 id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64 1044 ; 'certificateHold' 1045 id-privilegeWithdrawn = 1046 %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E 1047 ; 'privilegeWithdrawn' 1048 id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65 1049 ; 'aACompromise' 1051 A.7. AlgorithmIdentifier 1052 AlgorithmIdentifier = "{" sp ai-algorithm 1053 [ "," sp ai-parameters ] sp "}" 1055 ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER 1056 ai-parameters = id-parameters msp Value 1057 id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm' 1058 id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters' 1060 Intellectual Property Rights 1062 The IETF takes no position regarding the validity or scope of any 1063 Intellectual Property Rights or other rights that might be claimed to 1064 pertain to the implementation or use of the technology described in 1065 this document or the extent to which any license under such rights 1066 might or might not be available; nor does it represent that it has 1067 made any independent effort to identify any such rights. Information 1068 on the procedures with respect to rights in RFC documents can be found 1069 in BCP 78 and BCP 79. 1071 Copies of IPR disclosures made to the IETF Secretariat and any 1072 assurances of licenses to be made available, or the result of an 1073 attempt made to obtain a general license or permission for the use of 1074 such proprietary rights by implementers or users of this specification 1075 can be obtained from the IETF on-line IPR repository at 1076 http://www.ietf.org/ipr. 1078 The IETF invites any interested party to bring to its attention any 1079 copyrights, patents or patent applications, or other proprietary 1080 rights that may cover technology that may be required to implement 1081 this standard. Please address the information to the IETF at 1082 ietf-ipr@ietf.org. 1084 Full Copyright 1086 Copyright (C) The Internet Society (2005). 1088 This document is subject to the rights, licenses and restrictions 1089 contained in BCP 78, and except as set forth therein, the authors 1090 retain all their rights. 1092 This document and the information contained herein are provided on an 1093 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1094 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1095 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1096 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1097 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1098 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.