idnits 2.17.00 (12 Aug 2021) /tmp/idnits62487/draft-ietf-pkix-ldap-schema-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1842 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 133 instances of lines with control characters in the document. ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 35 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 515 has weird spacing: '...ubtrees msp G...' == Line 528 has weird spacing: '...id-base msp...' == Line 693 has weird spacing: '...onFlags msp R...' == Line 694 has weird spacing: '...AndTime msp T...' == Line 935 has weird spacing: '...estInfo msp O...' == (10 more instances...) -- 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 (16 November 2001) is 7490 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: '0' is mentioned on line 1006, but not defined == Unused Reference: '6' is defined on line 1601, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1777 (ref. '2') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2253 (ref. '6') (Obsoleted by RFC 4510, RFC 4514) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2587 (ref. '8') (Obsoleted by RFC 4523) -- Possible downref: Non-RFC (?) normative reference: ref. '9' ** Obsolete normative reference: RFC 2234 (ref. '10') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 1778 (ref. '12') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT D. W. Chadwick 2 PKIX WG University of Salford 3 Intended Category: Standards Track S. Legg 4 Adacel Technologies 5 16 November 2001 7 Internet X.509 Public Key Infrastructure 8 LDAP Schema and Syntaxes for PKIs and PMIs 9 11 Copyright (C) The Internet Society (2001). All Rights Reserved. 13 STATUS OF THIS MEMO 15 This document is an Internet-Draft and is in full conformance with 16 all the provisions of Section 10 of RFC2026 [1]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Comments and suggestions on this document are encouraged. Comments on 34 this document should be sent to the PKIX working group discussion list 35 or directly to the authors. 37 This Internet-Draft expires on 16 May 2002. 39 ABSTRACT 41 This document describes LDAP schema features that are needed to support 42 X.509 Public Key Infrastructures and Privilege Management 43 Infrastructures. Specifically, X.509 attribute types, object classes, 44 matching rules, attribute value syntaxes and attribute value assertion 45 syntaxes are defined. 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [5]. 51 1. Introduction 53 RFC2587 [8] describes some of the subschema applicable to LDAPv2 servers 54 [2], specifically the public key certificate related attribute types and 55 object classes that MUST or MAY be supported. This 56 [document/ID/standard] does not revoke any of the contents of RFC2587, 57 but supplements them. 59 RFC2587 is equally applicable to LDAPv3 [4] servers as to LDAPv2 servers 60 and MUST be supported by LDAPv3 servers. 62 Finally none of the previously cited documents mention 63 attributeCertificates or any schema to support privilege management 64 infrastructures, so this [document/ID/standard] rectifies this 65 deficiency. 67 2. Subschema Publishing 69 LDAPv3 allows the subschema supported by a server to be published in a 70 subschema subentry. Clients following this profile which support the 71 Search operation containing an extensible matching rule SHOULD use the 72 subschemaSubentry attribute in the root DSE to find the 73 subschemaSubentry, and SHOULD use the matchingRule and matchingRuleUse 74 operational attributes in the subschema subentry in order to determine 75 whether the server supports the various matching rules described below. 76 Servers that support extensible matching SHOULD publish the matching 77 rules they support in the matchingRule and matchingRuleUse operational 78 attributes. 80 3. Public Key Certificate and CRL Attributes and Syntaxes 82 3.1 userCertificate Attribute 84 The userCertificate attribute type contains the public-key certificates 85 a user has obtained from one or more CAs. This attribute is to be stored 86 and requested in the binary form, as 'userCertificate;binary'. 88 ( 2.5.4.36 NAME 'userCertificate' 89 EQUALITY certificateExactMatch 90 SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) 92 3.2 cACertificate Attribute 94 The cACertificate attribute of a CA's directory entry shall be used to 95 store self-issued certificates (if any) and certificates issued to this 96 CA by CAs in the same realm as this CA. This attribute is to be stored 97 and requested in the binary form, as 'cACertificate;binary'. 99 ( 2.5.4.37 NAME 'cACertificate' 100 EQUALITY certificateExactMatch 101 SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 ) 103 3.3 Certificate Syntax 105 A value in this syntax is the binary string that results from BER/DER- 106 encoding an X.509 public key certificate. The following string states 107 the OID assigned to this syntax: 109 ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) 111 Due to the changes from X.509(1988) to X.509(1993) and subsequent 112 changes to the ASN.1 definition to support certificate extensions, no 113 string representation is defined, and values in this syntax MUST only be 114 transferred using the binary encoding, by requesting or returning the 115 attributes with descriptions "userCertificate;binary" or 116 "caCertificate;binary". The BNF notation in RFC 1778 [12] for "User 117 Certificate" is not recommended to be used. 118 3.4 authorityRevocationList Attribute 120 A value of this attribute is a list of CA certificates that are no 121 longer valid. This attribute is to be stored and requested in the 122 binary form, as 'authorityRevocationList;binary'. 124 ( 2.5.4.38 NAME 'authorityRevocationList' 125 EQUALITY certificateListExactMatch 126 SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) 128 3.5 certificateRevocationList Attribute 130 A value of this attribute is a list of user certificates that are no 131 longer valid. This attribute is to be stored and requested in the 132 binary form, as 'certificateRevocationList;binary'. 134 ( 2.5.4.39 NAME 'certificateRevocationList' 135 EQUALITY certificateListExactMatch 136 SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) 138 3.6 deltaRevocationList Attribute 140 This attribute contains a list of revoked certificates (user or CA) that 141 is an addition to a previous certificate revocation list. This 142 attribute is to be stored and requested in the binary form, as 143 'deltaRevocationList;binary'. 145 ( 2.5.4.53 NAME 'deltaRevocationList' 146 EQUALITY certificateListExactMatch 147 SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) 149 3.7 Certificate List Syntax 151 A value in this syntax is the binary string that results from BER/DER- 152 encoding an X.509 certificate revocation list. The following string 153 states the OID assigned to this syntax: 155 ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' ) 157 Due to the incompatibility of the X.509(1988) and X.509(1993) 158 definitions of revocation lists, values in this syntax MUST only be 159 transferred using a binary encoding, by requesting or returning the 160 attributes with descriptions "certificateRevocationList;binary", 161 "authorityRevocationList;binary" or "deltaRevocationList;binary". The 162 BNF notation in RFC 1778 [12] for "Authority Revocation List" is not 163 recommended to be used. 164 3.8 crossCertificatePair Attribute 166 The following definition is taken from X.509(2000) [9]. The term forward 167 was used in earlier editions of X.509 for issuedToThisCA and the term 168 reverse was used in earlier editions for issuedByThisCA. 170 The issuedToThisCA elements of the crossCertificatePair attribute of a CA's 171 directory entry shall be used to store all, except self-issued 172 certificates, issued to this CA. Optionally, the issuedByThisCA elements 173 of the crossCertificatePair attribute, of a CA's directory entry may contain 174 a subset of certificates issued by this CA to other CAs. If a CA issues 175 a certificate to another CA, and the subject CA is not a subordinate to 176 the issuer CA in a hierarchy, then the issuer CA shall place that 177 certificate in the issuedByThisCA element of the crossCertificatePair attribute 178 of its own directory entry. When both the issuedToThisCA and the 179 issuedByThisCA elements are present in a single attribute value, issuer 180 name in one certificate shall match the subject name in the other and 181 vice versa, and the subject public key in one certificate shall be 182 capable of verifying the digital signature on the other certificate and 183 vice versa. 185 This attribute is to be stored and requested in the binary form, as 186 'crossCertificatePair;binary'. 188 ( 2.5.4.40 NAME 'crossCertificatePair' 189 EQUALITY certificatePairExactMatch 190 SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 ) 192 3.9 Certificate Pair Syntax 194 A value in this syntax is the binary string that results from BER/DER- 195 encoding an X.509 public key certificate pair. The following string 196 states the OID assigned to this syntax: 198 ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' ) 200 Values in this syntax MUST only be transferred using a binary encoding, 201 e.g. by requesting or returning the attribute description 202 "crossCertificatePair;binary". The BNF notation in RFC 1778 [12] for 203 "Certificate Pair" is not recommended to be used. 205 4. Public Key Certificate Matching Rules and Assertion Syntaxes 207 X.509 [9] supports both equality and flexible certificate matching rules 208 by the server, via the certificateExactMatch and certificateMatch 209 MATCHING-RULEs respectively. (For example, a client may flexibly search 210 for certificates with a particular validity time, key usage, policy or 211 other field.) LDAP servers MUST support the certificateExactMatch 212 matching rule. Clients MAY support certificateExactMatch values for 213 equalityMatch filters. LDAPv3 servers SHOULD support the 214 certificateMatch matching rule. If the server does support flexible 215 matching (either via certificateMatch or some other matching rule), then 216 the extensibleMatch filter of the Search request MUST be supported. 217 Clients MAY support the extensibleMatch filter and one or more of the 218 optional elements of certificateMatch. 220 Neither RFC2587 nor the user schema for LDAPv3 (RFC2256-bis [3]) nor the 221 attribute syntax definitions for LDAPv3 (RFC2252-bis [7]) describe the 222 certificate matching rules that should be supported by LDAP servers, nor 223 do they describe how attribute value assertions for each certificate 224 matching rule should be encoded in filter items. The native LDAP (i.e. 225 string) encodings for the assertion syntaxes defined in this document 226 are specified by the Generic String Encoding Rules in Section 8 of [13]. 227 The ABNF in this document for these assertion syntaxes is provided only 228 as a convenience and is equivalent to the encoding specified by the 229 application of [13]. Since the associated ASN.1 types for the assertion 230 syntaxes described here may be extended in future editions of X.509 [9], 231 the provided ABNF should be regarded as a snapshot in time. The native 232 LDAP encoding for any extension to a syntax's underlying ASN.1 type can 233 be determined from [13]. In the event that there is a discrepancy 234 between the ABNF in this document and the encoding determined by [13], 235 [13] is to be taken as definitive. 237 4.1 Certificate Exact Match 239 Certificate exact match is defined in 11.3.1 of [9]. The string 240 description of the certificateExactMatch matching rule is: 242 ( 2.5.13.34 NAME 'certificateExactMatch' 243 SYNTAX 1.2.826.0.1.3344810.7.1) 245 The LDAP syntax definition is: 247 (1.2.826.0.1.3344810.7.1 248 DESC 'CertificateExactAssertion (Serial Number and Issuer Name)' ) 250 The LDAP string encoding of an assertion value of this syntax is given 251 by the following Augmented BNF [10]: 253 CertificateExactAssertion = "{" sp cea-serialNumber "," 254 sp cea-issuer 255 sp "}" 257 cea-serialNumber = id-serialNumber msp CertificateSerialNumber 258 cea-issuer = id-issuer msp Name 260 id-serialNumber = %x73.65.72.69.61.6C.4E.75.6D.62.65.72 261 ; "serialNumber" 262 id-issuer = %x69.73.73.75.65.72 ; "issuer" 264 Name = id-rdnSequence ":" RDNSequence 265 id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; "rdnSequence" 267 CertificateSerialNumber = INTEGER 269 Note. [14] states that CAs MUST force the serialNumber to be a non- 270 negative integer. Non-conforming CAs MAY issue certificates with serial 271 numbers that are negative, or zero. Certificate users SHOULD be 272 prepared to handle such certificates. 274 The , , and rules are given in [16]. 276 4.2 Certificate Match 278 Certificate match is defined in 11.3.2 of [9]. The string description 279 of the certificateMatch matching rule is: 281 ( 2.5.13.35 NAME 'certificateMatch' 282 SYNTAX 1.2.826.0.1.3344810.7.2) 284 The syntax definition is: 286 (1.2.826.0.1.3344810.7.2 DESC 'Certificate Assertion' ) 288 The ASN.1 for CertificateAssertion is defined in 11.3.2 of [9], as 289 are the semantics of each of its component types. 291 The LDAP string encoding of an assertion value of this syntax is given 292 by the following ABNF: 294 CertificateAssertion = "{" [ sp ca-serialNumber ] 295 [ sep sp ca-issuer ] 296 [ sep sp ca-subjectKeyIdentifier ] 297 [ sep sp ca-authorityKeyIdentifier ] 298 [ sep sp ca-certificateValid ] 299 [ sep sp ca-privateKeyValid ] 300 [ sep sp ca-subjectPublicKeyAlgID ] 301 [ sep sp ca-keyUsage ] 302 [ sep sp ca-subjectAltName ] 303 [ sep sp ca-policy ] 304 [ sep sp ca-pathToName ] 305 [ sep sp ca-subject ] 306 [ sep sp ca-nameConstraints ] 307 sp "}" 309 The rule is given in [16]. 311 ca-serialNumber = id-serialNumber msp 312 CertificateSerialNumber 313 ca-issuer = id-issuer msp Name 314 ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp 315 SubjectKeyIdentifier 316 ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp 317 AuthorityKeyIdentifier 318 ca-certificateValid = certificateValid msp Time 319 ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime 320 ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp 321 OBJECT-IDENTIFIER 322 ca-keyUsage = id-keyUsage msp KeyUsage 323 ca-subjectAltName = id-subjectAltName msp AltNameType 324 ca-policy = id-policy msp CertPolicySet 325 ca-pathToName = id-pathToName msp Name 326 ca-subject = id-subject msp Name 327 ca-nameConstraints = id-nameConstraints msp 328 NameConstraintsSyntax 330 id-subjectKeyIdentifier = %x73.75.62.6A.65.63.74.4B.65.79.49.64.65 331 %x6E.74.69.66.69.65.72 332 ; "subjectKeyIdentifier" 333 id-authorityKeyIdentifier = %x61.75.74.68.6F.72.69.74.79.4B.65.79.49 334 %x64.65.6E.74.69.66.69.65.72 335 ; "authorityKeyIdentifier" 336 id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61 337 %x6C.69.64 ; "certificateValid" 338 id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C 339 %x69.64 ; "privateKeyValid" 340 id-subjectPublicKeyAlgID = %x73.75.62.6A.65.63.74.50.75.62.6C.69.63 341 %x4B.65.79.41.6C.67.49.44 342 ; "subjectPublicKeyAlgID" 343 id-keyUsage = %x6B.65.79.55.73.61.67.65 ; "keyUsage" 344 id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D 345 %x65 ; "subjectAltName" 346 id-policy = %x70.6F.6C.69.63.79 ; "policy" 347 id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 348 ; "pathToName" 349 id-subject = %x73.75.62.6A.65.63.74 ; "subject" 350 id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E 351 %x74.73 ; "nameConstraints" 353 SubjectKeyIdentifier = KeyIdentifier 355 KeyIdentifier = OCTET-STRING 357 AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ] 358 [ sep sp aki-authorityCertIssuer ] 359 [ sep sp aki-authorityCertSerialNumber ] 360 sp "}" 362 aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier 363 aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames 365 GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}" 366 GeneralName = gn-otherName 367 / gn-rfc822Name 368 / gn-dNSName 369 / gn-x400Address 370 / gn-directoryName 371 / gn-ediPartyName 372 / gn-uniformResourceIdentifier 373 / gn-iPAddress 374 / gn-registeredID 376 gn-otherName = id-otherName ":" OtherName 377 gn-rfc822Name = id-rfc822Name ":" IA5String 378 gn-dNSName = id-dNSName ":" IA5String 379 gn-x400Address = id-x400Address ":" ORAddress 380 gn-directoryName = id-directoryName ":" Name 381 gn-ediPartyName = id-ediPartyName ":" EDIPartyName 382 gn-iPAddress = id-iPAddress ":" OCTET-STRING 383 gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER 385 gn-uniformResourceIdentifier = id-uniformResourceIdentifier 386 ":" IA5String 388 id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; "otherName" 389 gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44 390 ; "registeredID" 392 OtherName = "{" sp on-type-id "," sp on-value sp "}" 393 on-type-id = id-type-id msp OBJECT-IDENTIFIER 394 on-value = id-value msp Value 395 id-type-id = %x74.79.70.65.2D.69.64 ; "type-id" 396 id-value = %x76.61.6C.75.65 ; "value" 398 The rule is defined in Section 8 of [13]. 400 ORAddress = dquote *SafeIA5Character dquote 401 SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote 402 dquote dquote ; escaped double quote 403 dquote = %x22 ; " (double quote) 405 The rule encodes the x400Address component of a GeneralName 406 as a character string between double quotes. The character string is 407 first derived according to Section 4.1 of [11], and then any embedded 408 double quotes are escaped by being repeated. This resulting string is 409 output between double quotes. 411 EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}" 412 nameAssigner = id-nameAssigner msp DirectoryString 413 partyName = id-partyName msp DirectoryString 414 id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72 415 ; "nameAssigner" 416 id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; "partyName" 418 aki-authorityCertSerialNumber = id-authorityCertSerialNumber msp 419 CertificateSerialNumber 421 id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72 422 ; "keyIdentifier" 423 id-authorityCertIssuer = %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49 424 %x73.73.75.65.72 ; "authorityCertIssuer" 426 id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43.65.72 427 %x74.53.65.72.69.61.6C.4E.75.6D.62 428 %x65.72 429 ; "authorityCertSerialNumber" 431 Time = time-utcTime / time-generalizedTime 432 time-utcTime = id-utcTime ":" UTCTime 433 time-generalizedTime = id-generalizedTime ":" GeneralizedTime 434 id-utcTime = %x75.74.63.54.69.6D.65 ; "utcTime" 435 id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65 436 ; "generalizedTime" 438 KeyUsage = BIT-STRING / key-usage-bit-list 439 key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}" 441 The rule encodes the one bits in a KeyUsage value 442 as a comma separated list of identifiers. The rule is given 443 in [16]. 445 key-usage = id-digitalSignature 446 / id-nonRepudiation 447 / id-keyEncipherment 448 / id-dataEncipherment 449 / id-keyAgreement 450 / id-keyCertSign 451 / id-cRLSign 452 / id-encipherOnly 453 / id-decipherOnly 455 id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74.75.72 456 %x65 ; "digitalSignature" 457 id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E 458 ; "nonRepudiation" 459 id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74 460 ; "keyEncipherment" 461 id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E 462 %x74 ; "dataEncipherment" 463 id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74 464 ; "keyAgreement" 465 id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E 466 ; "keyCertSign" 467 id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign" 468 id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79 469 ; "encipherOnly" 470 id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79 471 ; "decipherOnly" 473 AltNameType = ant-builtinNameForm / ant-otherNameForm 475 ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm 476 ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER 478 id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D 479 ; "builtinNameForm" 480 id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D 481 ; "otherNameForm" 483 BuiltinNameForm = id-rfc822Name 484 / id-dNSName 485 / id-x400Address 486 / id-directoryName 487 / id-ediPartyName 488 / id-uniformResourceIdentifier 489 / id-iPAddress 490 / id-registeredId 491 id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; "rfc822Name" 492 id-dNSName = %x64.4E.53.4E.61.6D.65 ; "dNSName" 493 id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 494 ; "x400Address" 495 id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65 496 ; "directoryName" 497 id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65 498 ; "ediPartyName" 499 id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; "iPAddress" 500 id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64 501 ; "registeredId" 503 id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75 504 %x72.63.65.49.64.65.6E.74.69.66.69.65 505 %x72 ; "uniformResourceIdentifier" 507 CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}" 508 CertPolicyId = OBJECT-IDENTIFIER 510 NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ] 511 [ sep sp ncs-excludedSubtrees ] 512 sp "}" 514 ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees 515 ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees 516 id-permittedSubtrees = %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72 517 %x65.65.73 ; "permittedSubtrees" 518 id-excludedSubtrees = %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65 519 %x65.73 ; "excludedSubtrees" 521 GeneralSubtrees = "{" sp GeneralSubtree 522 *( "," sp GeneralSubtree ) sp "}" 523 GeneralSubtree = "{" sp gs-base 524 [ "," sp gs-minimum ] 525 [ "," sp gs-maximum ] 526 sp "}" 528 gs-base = id-base msp GeneralName 529 gs-minimum = id-minimum msp BaseDistance 530 gs-maximum = id-maximum msp BaseDistance 531 id-base = %x62.61.73.65 ; "base" 532 id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum" 533 id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum" 534 BaseDistance = INTEGER-0-MAX 536 The , , , , 537 , , and rules are given in [16]. 540 4.3 Certificate Pair Exact Match 542 Certificate pair exact match is defined in 11.3.3 of [9]. The string 543 description of the certificatePairExactMatch matching rule is: 545 ( 2.5.13.36 NAME 'certificatePairExactMatch' 546 SYNTAX 1.2.826.0.1.3344810.7.8) 548 The LDAP syntax definition is: 550 (1.2.826.0.1.3344810.7.8 551 DESC 'Certificate Pair Exact Assertion' ) 553 The ASN.1 for CertificatePairExactAssertion is defined in 11.3.3 of [9], 554 as are the semantics of each of its component types. 556 The LDAP string encoding of an assertion value of this syntax is given 557 by the following Augmented BNF [10]: 559 CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ] 560 [sep sp cpea-issuedBy ] 561 sp "}" 563 At least one of or MUST be present. 565 cpea-issuedTo = id-issuedToThisCAAssertion msp 566 CertificateExactAssertion 567 cpea-issuedBy = id-issuedByThisCAAssertion msp 568 CertificateExactAssertion 570 id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73.43 571 %x41.41.73.73.65.72.74.69.6F.6E 572 ; "issuedToThisCAAssertion" 573 id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73.43 574 %x41.41.73.73.65.72.74.69.6F.6E 575 ; "issuedByThisCAAssertion" 577 4.4 Certificate Pair Match 579 Certificate pair match is defined in 11.3.4 of [9]. The string 580 description of the certificatePairMatch matching rule is: 582 ( 2.5.13.37 NAME 'certificatePairExactMatch' 583 SYNTAX 1.2.826.0.1.3344810.7.9) 585 The LDAP syntax definition is: 587 (1.2.826.0.1.3344810.7.9 588 DESC 'Certificate Pair Assertion' ) 590 The ASN.1 for CertificatePairAssertion is defined in 11.3.4 of [9], as 591 are the semantics of each of its component types. 593 The LDAP string encoding of an assertion value of this syntax is given 594 by the following Augmented BNF [10]: 596 CertificatePairAssertion = "{" [ sp cpa-issuedTo ] 597 [sep sp cpa-issuedBy ] 598 sp "}" 600 At least one of and MUST be present. 602 cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion 603 cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion 605 5 Certificate Revocation List Matching Rules 607 X.509[9] defines both equality and flexible matching rules for CRLs, via 608 the certificateListExactMatch and certificateListMatch MATCHING-RULEs 609 respectively. LDAP servers MUST support the certificateListExactMatch 610 matching rule. Clients MAY support certificateListExactMatch values for 611 equalityMatch filters. LDAPv3 servers MAY support the 612 certificateListMatch matching rule. If the server does support flexible 613 matching (either via certificateListMatch or some other matching rule), 614 then the extensibleMatch filter of the Search request MUST be supported. 615 Clients MAY support the extensibleMatch filter and one or more of the 616 optional elements of certificateListMatch. 618 5.1 Certificate List Exact Match 620 Certificate List exact match is defined in 11.3.5 of [9]. The string 621 description of the certificateListExactMatch matching rule is: 623 ( 2.5.13.38 NAME 'certificateListExactMatch' 624 SYNTAX 1.2.826.0.1.3344810.7.3) 626 The syntax definition is: 628 (1.2.826.0.1.3344810.7.3 DESC 'Certificate List Exact Assertion (Issuer 629 name, time and distribution point name)' ) 631 The ASN.1 for CertificateListExactAssertion is defined in 11.3.5 of [9], 632 as are the semantics of each of its component types. 634 The LDAP string encoding of an assertion value of this syntax is given 635 by the following ABNF: 637 CertificateListExactAssertion = "{" sp clea-issuer 638 "," sp clea-thisUpdate 639 [ "," sp clea-distributionPoint ] 640 sp "}" 642 clea-issuer = id-issuer msp Name 643 clea-thisUpdate = id-thisUpdate msp Time 644 clea-distributionPoint = id-distributionPoint msp 645 DistributionPointName 647 id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 648 ; "thisUpdate" 649 id-distributionPoint = %x64.69.73.74.72.69.62.75.74.69.6F.6E 650 %x50.6F.69.6E.74 ; "distributionPoint" 652 DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer 654 dpn-fullName = id-fullName ":" GeneralNames 655 dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":" 656 RelativeDistinguishedName 658 id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; "fullName" 659 id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65 660 %x54.6F.43.52.4C.49.73.73.75.65.72 661 ; "nameRelativeToCRLIssuer" 663 5.2 Certificate List Match 665 Certificate List match is defined in 11.3.6 of [9]. The string 666 description of the certificateListMatch matching rule is: 668 ( 2.5.13.39 NAME 'certificateListMatch' 669 SYNTAX 1.2.826.0.1.3344810.7.4) 671 The syntax definition is: 673 (1.2.826.0.1.3344810.7.4 DESC 'Certificate List Assertion' ) 675 The ASN.1 for CertificateListAssertion is defined in 11.3.6 of [9], as 676 are the semantics of its components. 678 The LDAP string encoding of an assertion value of this syntax is given 679 by the following ABNF: 681 CertificateListAssertion = "{" [ sp cla-issuer ] 682 [ sep sp cla-minCRLNumber ] 683 [ sep sp cla-maxCRLNumber ] 684 [ sep sp cla-reasonFlags ] 685 [ sep sp cla-dateAndTime ] 686 [ sep sp cla-distributionPoint ] 687 [ sep sp cla-authorityKeyIdentifier ] 688 sp "}" 690 cla-issuer = id-issuer msp Name 691 cla-minCRLNumber = id-minCRLNumber msp CRLNumber 692 cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber 693 cla-reasonFlags = id-reasonFlags msp ReasonFlags 694 cla-dateAndTime = id-dateAndTime msp Time 696 cla-distributionPoint = id-distributionPoint msp 697 DistributionPointName 698 cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp 699 AuthorityKeyIdentifier 701 id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72 702 ; "minCRLNumber" 703 id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72 704 ; "maxCRLNumber" 705 id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; "reasonFlags" 706 id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; "dateAndTime" 708 CRLNumber = INTEGER-0-MAX 710 ReasonFlags = BIT-STRING 711 / "{" [ sp reason-flag 712 *( "," sp reason-flag ) ] sp "}" 714 reason-flag = id-unused 715 / id-keyCompromise 716 / id-cACompromise 717 / id-affiliationChanged 718 / id-superseded 719 / id-cessationOfOperation 720 / id-certificateHold 721 / id-privilegeWithdrawn 722 / id-aACompromise 724 id-unused = %x75.6E.75.73.65.64 ; "unused" 725 id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65 726 ; "keyCompromise" 727 id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65 728 ; "cACompromise" 729 id-affiliationChanged = %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68 730 %x61.6E.67.65.64 ; "affiliationChanged" 731 id-superseded = %x73.75.70.65.72.73.65.64.65.64 732 ; "superseded" 733 id-cessationOfOperation = %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70 734 %x65.72.61.74.69.6F.6E 735 ; "cessationOfOperation" 736 id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F 737 %x6C.64 ; "certificateHold" 738 id-privilegeWithdrawn = %x70.72.69.76.69.6C.65.67.65.57.69.74.68 739 %x64.72.61.77.6E ; "privilegeWithdrawn" 740 id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65 741 ; "aACompromise" 743 6. Privilege Management Attribute Certificate and CRL Attributes 744 and Syntaxes 746 LDAP servers MAY store any type of attribute with the 747 AttributeCertificate syntax, and LDAP clients MAY request them to be 748 returned by adding them to the Search Request AttributeDescriptionList 749 (either explicitly or implicity via requesting all attributes). 751 6.1 Attribute Certificate Attribute 753 The attributeCertificateAttribute is defined in 17.2.1 of [9]. It is 754 used to hold the attribute certificates of a user. 756 attributeCertificateAttribute ATTRIBUTE ::= { 757 WITH SYNTAX AttributeCertificate 758 EQUALITY MATCHING RULE attributeCertificateExactMatch 759 ID { joint-iso-ccitt(2) ds(5) attributeType(4) 760 attributeCertificate(58) } } 762 The corresponding LDAP description is 764 ( 2.5.4.58 NAME 'attributeCertificateAttribute' 765 EQUALITY attributeCertificateExactMatch 766 SYNTAX 1.2.826.0.1.3344810.7.5 ) 768 6.2 Attribute Authority Certificate Attribute 770 The attribute authority attribute certificate is defined in 17.2.2 of 771 [9]. The aAcertificate attribute holds the privileges of an attribute 772 authority. 774 aACertificate ATTRIBUTE ::= { 775 WITH SYNTAX AttributeCertificate 776 EQUALITY MATCHING RULE attributeCertificateExactMatch 777 ID { joint-iso-ccitt(2) ds(5) attributeType(4) 778 aACertificate(61) } } 780 The corresponding LDAP description is 782 ( 2.5.4.61 NAME 'aACertificate' 783 EQUALITY attributeCertificateExactMatch 784 SYNTAX 1.2.826.0.1.3344810.7.5 ) 785 6.3 Attribute Descriptor Certificate Attribute 787 The attributeDescriptorCertificate attribute is defined in 17.2.3 of 788 [9]. The certificate is self signed by a source of authority and holds a 789 description of the privilege and its delegation rules. 791 attributeDescriptorCertificate ATTRIBUTE ::= { 792 WITH SYNTAX AttributeCertificate 793 EQUALITY MATCHING RULE attributeCertificateExactMatch 794 ID { joint-iso-ccitt(2) ds(5) attributeType(4) 795 attributeDescriptorCertificate (62) } } 797 The corresponding LDAP description is 799 ( 2.5.4.62 NAME 'attributeDescriptorCertificate' 800 EQUALITY attributeCertificateExactMatch 801 SYNTAX 1.2.826.0.1.3344810.7.5 ) 803 6.4 Attribute Certificate Syntax 805 A value in this syntax is the binary string that results from BER/DER- 806 encoding an X.509 attribute certificate. The following string states 807 the OID assigned to this syntax: 809 (1.2.826.0.1.3344810.7.5 DESC 'Attribute Certificate' ) 811 6.5 Attribute Certificate Revocation List Attribute 813 The attributeCertificateRevocationList attribute is defined in section 814 17.2.4 of [9]. It holds a list of attribute certificates that have been 815 revoked. 817 attributeCertificateRevocationList ATTRIBUTE ::= { 818 WITH SYNTAX CertificateList 819 EQUALITY MATCHING RULE certificateListExactMatch 820 ID { joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) } } 822 The corresponding LDAP description is 824 ( 2.5.4.59 NAME 'attributeCertificateRevocationList' 825 EQUALITY certificateListExactMatch 826 SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) 828 6.6 Attribute Authority Certificate Revocation List Attribute 830 The attribute authority certificate revocation list attribute is defined 831 in section 17.2.5 of [9]. It holds a list of AA certificates that have 832 been revoked. 834 attributeAuthorityRevocationList ATTRIBUTE ::= { 835 WITH SYNTAX CertificateList 836 EQUALITY MATCHING RULE certificateListExactMatch 837 ID { joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) } } 839 The corresponding LDAP description is 841 ( 2.5.4.63 NAME 'attributeAuthorityRevocationList' 842 EQUALITY certificateListExactMatch 843 SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 ) 845 7 PMI Matching Rules 847 LDAP servers that support the storage of attributes with the 848 AttributeCertificate syntax MUST support searching for entries 849 containing specific attribute certificates, via the 850 attributeCertificateExactMatch matching rule. 852 LDAPv3Servers MAY support flexible matching for any attributes with the 853 AttributeCertificate syntax via the attributeCertificateMatch matching 854 rule or any of the matching rules defined for the certificate 855 extensions. LDAPv3 servers SHOULD publish the matching rules that they 856 do support in the matchingRule and matchingRuleUse operational 857 attributes of the subschema subentry. If the server does support 858 flexible matching (either via attributeCertificateMatch or some other 859 matching rule), then the extensibleMatch filter of the Search request 860 MUST be supported. LDAPv3 clients MAY support the extensibleMatch 861 filter of the Search operation, along one or more of the optional 862 elements of attributeCertificateMatch or any of the certificate 863 extension matching rules. 865 7.1 Attribute Certificate Exact Match 867 The equality matching rule for all types of attribute with 868 AttributeCertificate syntax is the attributeCertificateExactMatch, 869 This is defined in 17.3.1 of [9]. It is reproduced below for the 870 convenience of the reader (but see Outstanding Issue iv). 872 attributeCertificateExactMatch MATCHING-RULE ::= { 873 SYNTAX AttributeCertificateExactAssertion 874 ID { joint-iso-ccitt(2) ds(5) mr (13) 875 attributeCertificateExactMatch (45) } } 877 AttributeCertificateExactAssertion ::= SEQUENCE { 878 serialNumber CertificateSerialNumber, 879 issuer AttCertIssuer } 881 CertificateSerialNumber ::= INTEGER 883 AttCertIssuer ::= [0] SEQUENCE { 884 issuerName GeneralNames OPTIONAL, 885 baseCertificateID [0] IssuerSerial OPTIONAL, 886 objectDigestInfo [1] ObjectDigestInfo OPTIONAL } 887 -- At least one component shall be present 889 IssuerSerial ::= SEQUENCE { 890 issuer GeneralNames, 891 serial CertificateSerialNumber, 892 issuerUID UniqueIdentifier OPTIONAL } 894 UniqueIdentifier ::= BIT STRING 896 ObjectDigestInfo ::= SEQUENCE { 897 digestedObjectType ENUMERATED { 898 publicKey (0), 899 publicKeyCert (1), 900 otherObjectTypes (2) }, 901 otherObjectTypeID OBJECT IDENTIFIER OPTIONAL, 902 digestAlgorithm AlgorithmIdentifier, 903 objectDigest BIT STRING } 905 The LDAP definition for the above matching rule is: 907 ( 2.5.13.45 NAME 'attributeCertificateExactMatch' 908 SYNTAX 1.2.826.0.1.3344810.7.6) 910 The syntax definition is: 912 (1.2.826.0.1.3344810.7.6 DESC 'Attribute certificate exact assertion ( 913 serial number and issuer details)' ) 915 The LDAP string encoding of an assertion value of this syntax is given 916 by the following ABNF: 918 AttributeCertificateExactAssertion = "{" sp acea-serialNumber "," 919 sp acea-issuer 920 sp "}" 922 acea-serialNumber = id-serialNumber msp CertificateSerialNumber 923 acea-issuer = id-issuer msp AttCertIssuer 925 AttCertIssuer = "{" [ sp aci-issuerName ] 926 [ sep sp aci-baseCertificateID ] 927 [ sep sp aci-objectDigestInfo ] 928 sp "}" 930 At least one of , or 931 MUST be present. 933 aci-issuerName = id-issuerName msp GeneralNames 934 aci-baseCertificateID = id-baseCertificateID msp IssuerSerial 935 aci-objectDigestInfo = id-objectDigestInfo msp ObjectDigestInfo 936 id-issuerName = %x69.73.73.75.65.72.4E.61.6D.65 937 ; "issuerName" 938 id-objectDigestInfo = %x6F.62.6A.65.63.74.44.69.67.65.73.74.49.6E 939 %x66.6F ; "objectDigestInfo" 941 ObjectDigestInfo = "{" sp odi-digestedObjectType 942 [ "," sp odi-otherObjectTypeID ] 943 "," sp odi-digestAlgorithm 944 "," sp odi-objectDigest 945 sp "}" 947 odi-digestedObjectType = id-digestedObjectType msp 948 DigestedObjectType 949 odi-otherObjectTypeID = id-otherObjectTypeID msp OBJECT-IDENTIFIER 950 odi-digestAlgorithm = id-digestAlgorithm msp AlgorithmIdentifier 951 odi-objectDigest = id-objectDigest msp BIT-STRING 953 id-digestedObjectType = %x64.69.67.65.73.74.65.64.4F.62.6A.65.63.74 954 %x54.79.70.65 ; "digestedObjectType" 955 id-otherObjectTypeID = %x6F.74.68.65.72.4F.62.6A.65.63.74.54.79.70 956 %x65.49.44 ; "otherObjectTypeID" 957 id-digestAlgorithm = %x64.69.67.65.73.74.41.6C.67.6F.72.69.74.68 958 %x6D ; "digestAlgorithm" 959 id-objectDigest = %x6F.62.6A.65.63.74.44.69.67.65.73.74 960 ; "objectDigest" 962 DigestedObjectType = id-publicKey 963 / id-publicKeyCert 964 / id-otherObjectTypes 965 id-publicKey = %x70.75.62.6C.69.63.4B.65.79 ; "publicKey" 966 id-publicKeyCert = %x70.75.62.6C.69.63.4B.65.79.43.65.72.74 967 ; "publicKeyCert" 968 id-otherObjectTypes = %x6F.74.68.65.72.4F.62.6A.65.63.74.54.79.70.65 969 %x73 ; "otherObjectTypes" 971 AlgorithmIdentifier = "{" sp ai-algorithm 972 [ "," sp ai-parameters ] 973 sp "}" 975 ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER 976 ai-parameters = id-parameters msp Value 977 id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; "algorithm" 978 id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; "parameters" 980 IssuerSerial = "{" sp is-issuer 981 "," sp is-serial 982 [ "," sp is-issuerUID ] 983 sp "}" 985 is-issuer = id-issuer msp GeneralNames 986 is-serial = id-serial msp CertificateSerialNumber 987 is-issuerUID = id-issuerUID msp UniqueIdentifier 989 id-serial = %x73.65.72.69.61.6C ; "serial" 990 id-issuerUID = %x69.73.73.75.65.72.55.49.44 ; "issuerUID" 992 UniqueIdentifier = BIT-STRING 994 7.2 Attribute Certificate Match 996 Attribute certificate matching rule is defined in section 17.3.2 of 997 [9]. For the convenience of the reader it is reproduced below: 999 attributeCertificateMatch MATCHING-RULE ::= { 1000 SYNTAX AttributeCertificateAssertion 1001 ID { joint-iso-ccitt(2) ds(5) mr (13) 1002 attributeCertificateMatch (42) } 1004 AttributeCertificateAssertion ::= SEQUENCE { 1005 holder [0] CHOICE { 1006 baseCertificateID [0] IssuerSerial, 1007 subjectName [1] GeneralNames 1008 } OPTIONAL, 1009 issuer [1] GeneralNames OPTIONAL, 1010 attCertValidity [2] GeneralizedTime OPTIONAL, 1011 attType [3] SET OF AttributeType OPTIONAL } 1012 --At least one component of the sequence must be present 1014 The LDAP definition of the attributeCertificateMatch matching rule 1015 is: 1017 ( 2.5.13.42 NAME 'attributeCertificateMatch' 1018 SYNTAX 1.2.826.0.1.3344810.7.7 ) 1020 The syntax definition is: 1022 (1.2.826.0.1.3344810.7.7 1023 DESC 'Attribute Certificate Assertion' ) 1025 The LDAP string encoding of an assertion value of this syntax is given 1026 by the following ABNF: 1028 AttributeCertificateAssertion = "{" [ sp aca-holder ] 1029 [ sep sp aca-issuer ] 1030 [ sep sp aca-attCertValidity ] 1031 [ sep sp aca-attType ] 1032 sp "}" 1034 aca-holder = id-holder msp ACAHolder 1035 aca-issuer = id-issuer msp GeneralNames 1036 aca-attCertValidity = id-attCertValidity msp GeneralizedTime 1037 aca-attType = id-attType msp SETOFAttributeType 1039 ACAHolder = acah-baseCertificateID / acah-holderName 1041 acah-baseCertificateID = id-baseCertificateID ":" IssuerSerial 1042 acah-holderName = id-holderName ":" GeneralNames 1044 id-baseCertificateID = %x62.61.73.65.43.65.72.74.69.66.69.63.61.74 1045 %x65.49.44 ; "baseCertificateID" 1046 id-holderName = %x68.6F.6C.64.65.72.4E.61.6D.65 1047 ; "holderName" 1049 SETOFAttributeType = "{" sp AttributeType 1050 *( "," sp AttributeType ) sp "}" 1052 The rule is given in [16]. 1054 8 AC Extensions Matching Rules 1056 X.509 defines the following matching rules for matching on various 1057 extensions within an attribute certificate. 1058 8.1 Holder Issuer Match 1059 Holder Issuer Match is described in section 17.3.3 of [9]. The string 1060 description of the holderIssuerMatch matching rule is: 1062 ( 2.5.13.46 NAME 'holderIssuerMatch' 1063 SYNTAX 1.2.826.0.1.3344810.7.10) 1065 The syntax definition is: 1067 (1.2.826.0.1.3344810.7.10 DESC 'Holder Issuer Assertion' ) 1069 The ASN.1 for HolderIssuerAssertion is defined in 17.3.3 of [9], as are 1070 the semantics of its components. 1072 The LDAP string encoding of an assertion value of this syntax is given 1073 by the following ABNF: 1075 HolderIssuerAssertion = "{" [ sp hia-holder ] 1076 [ sep sp hia-issuer ] 1077 sp "}" 1079 hia-holder = id-holder msp Holder 1080 hia-issuer = id-issuer msp AttCertIssuer 1082 Holder = "{" [ sp h-baseCertificateID ] 1083 [ sep sp h-entityName ] 1084 [ sep sp h-objectDigestInfo ] 1085 sp "}" 1087 At least one of , or 1088 MUST be present. 1090 h-baseCertificateID = id-baseCertificateID msp IssuerSerial 1091 h-entityName = id-entityName msp GeneralNames 1092 h-objectDigestInfo = id-objectDigestInfo msp ObjectDigestInfo 1093 id-entityName = %x65.6E.74.69.74.79.4E.61.6D.65 ; "entityName" 1095 8.2 Delegation Path Match 1097 Delegation Path Match is described in section 17.3.4 of [9]. The string 1098 description of the delegationPathMatch matching rule is: 1100 ( 2.5.13.61 NAME 'delegationPathMatch' 1101 SYNTAX 1.2.826.0.1.3344810.7.10) 1103 The syntax definition is: 1105 (1.2.826.0.1.3344810.7.10 DESC 'DelMatchSyntax' ) 1107 The ASN.1 for DelMatchSyntax is defined in 17.3.4 of [9], as are the 1108 semantics of its components. 1110 The LDAP string encoding of an assertion value of this syntax is given 1111 by the following ABNF: 1113 DelMatchSyntax = "{" sp dms-firstIssuer "," 1114 sp dms-lastHolder 1115 sp "}" 1116 dms-firstIssuer = id-firstIssuer msp AttCertIssuer 1117 dms-lastHolder = id-lastHolder msp Holder 1118 id-firstIssuer = %x66.69.72.73.74.49.73.73.75.65.72 ; "firstIssuer" 1119 id-lastHolder = %x6C.61.73.74.48.6F.6C.64.65.72 ; "lastHolder" 1121 8.3 Authority Attribute Identifier Match 1123 Authority Attribute Identifier Match is described in section 15.5.2.4.1 1124 of [9]. The string description of the authAttIdMatch matching rule is: 1126 ( 2.5.13.53 NAME 'authAttIdMatch' 1127 SYNTAX 1.2.826.0.1.3344810.7.12) 1129 The syntax definition is: 1131 (1.2.826.0.1.3344810.7.12 DESC 'Authority Attribute Identifier Syntax' ) 1133 The ASN.1 for AuthorityAttributeIdentifierSyntax is defined in 15.5.2.4 1134 of [9], as are the semantics of its components. 1136 The LDAP string encoding of an assertion value of this syntax is given 1137 by the following ABNF: 1139 AuthorityAttributeIdentifierSyntax = "{" sp AuthAttId 1140 *( "," sp AuthAttId ) sp "}" 1142 AuthAttId = IssuerSerial 1144 8.4 Role Specification Certificate Identifier Match 1146 Role Specification Certificate Identifier match is described in section 1147 15.4.2.1.1 of [9]. The string description of the roleSpecCertIdMatch 1148 Match matching rule is: 1150 ( 2.5.13.54 NAME 'roleSpecCertIdMatch ' 1151 SYNTAX 1.2.826.0.1.3344810.7.13) 1153 The syntax definition is: 1155 (1.2.826.0.1.3344810.7.13 DESC 'Role Specification Ceritificate 1156 Identifier Syntax' ) 1158 The ASN.1 for RoleSpecCertIdentifierSyntax is defined in 15.4.2.1 of 1159 [9], as are the semantics of its components. 1161 The LDAP string encoding of an assertion value of this syntax is given 1162 by the following ABNF: 1164 RoleSpecCertIdentifierSyntax = "{" sp RoleCertSpecIdentifier 1165 *( "," sp RoleCertSpecIdentifier ) sp "}" 1166 RoleCertSpecIdentifier = "{" sp rsci-roleName 1167 "," sp rsci-roleCertIssuer 1168 [ "," sp rsci-roleCertSerialNumber ] 1169 [ "," sp rsci-roleCertLocator ] 1170 sp "}" 1171 rsci-roleName = id-roleName msp GeneralName 1172 rsci-roleCertIssuer = id-roleCertIssuer msp GeneralName 1173 rsci-roleCertSerialNumber = id-roleCertSerialNumber msp 1174 CertificateSerialNumber 1175 rsci-roleCertLocator = id-roleCertLocator msp GeneralName 1176 id-roleName = %x72.6F.6C.65.4E.61.6D.65 ; "roleName" 1177 id-roleCertIssuer = %x72.6F.6C.65.43.65.72.74.49.73.73.75.65 1178 %x72 ; "roleCertIssuer" 1179 id-roleCertSerialNumber = %x72.6F.6C.65.43.65.72.74.53.65.72.69.61 1180 %x6C.4E.75.6D.62.65.72 1181 ; "roleCertSerialNumber" 1182 id-roleCertLocator = %x72.6F.6C.65.43.65.72.74.4C.6F.63.61.74 1183 %x6F.72 ; "roleCertLocator" 1185 8.5 Basic Attribute Constraints Match 1187 Basic Attribute Constraints Match is described in section 15.5.2.1.1 of 1188 [9]. The string 1189 description of the holderIssuerMatch matching rule is: 1191 ( 2.5.13.55 NAME ' basicAttConstraintsMatch ' 1192 SYNTAX 1.2.826.0.1.3344810.7.14) 1194 The syntax definition is: 1196 (1.2.826.0.1.3344810.7.14 DESC 'Basic Attributes Constraints Syntax' ) 1198 The ASN.1 for BasicAttConstraintsSyntax is defined in 15.5.2.1 of [9], 1199 as are the semantics of its components. 1201 The LDAP string encoding of an assertion value of this syntax is given 1202 by the following ABNF: 1204 BasicAttConstraintsSyntax = "{" [ sp bacm-authority ] 1205 [ sep sp bacm-pathLenConstraint ] 1206 sp "}" 1207 bacm-authority = id-authority msp BOOLEAN 1208 bacm-pathLenConstraint = id-pathLenConstraint msp INTEGER-0-MAX 1209 id-authority = %x61.75.74.68.6F.72.69.74.79 ; "authority" 1210 id-pathLenConstraint = %x70.61.74.68.4C.65.6E.43.6F.6E.73.74.72.61 1211 %x69.6E.74 ; "pathLenConstraint" 1213 The rule is given in [16]. 1215 8.6 Delegated Name Constraints Match 1217 Delegated Name Constraints Match is described in section 15.5.2.2.1 of 1218 [9]. The string description of the holderIssuerMatch matching rule is: 1220 ( 2.5.13.56 NAME ' delegatedNameConstraintsMatch' 1221 SYNTAX 1.2.826.0.1.3344810.7.15) 1223 The syntax definition is: 1225 (1.2.826.0.1.3344810.7.15 DESC 'Name Constraints Syntax' ) 1227 The ASN.1 for NameConstraintsSyntax is defined in 8.4.2.2 of [9], and 1228 the semantics of its components when used for delegated name constraints 1229 are described in 15.5.2.2. 1231 The LDAP string encoding of an assertion value of this syntax is given 1232 in Section 4.2. 1234 8.7 Time Specification Match 1236 Time Specification Match is described in section 15.1.2.1.1 of [9]. The 1237 string description of the timeSpecificationMatch matching rule is: 1239 ( 2.5.13.57 NAME ' timeSpecificationMatch ' 1240 SYNTAX 1.2.826.0.1.3344810.7.16) 1242 The syntax definition is: 1244 (1.2.826.0.1.3344810.7.16 DESC 'Time Specification' ) 1246 The ASN.1 for TimeSpecification is defined in 7.2 of [15], as are the 1247 semantics of its components. 1249 The LDAP string encoding of an assertion value of this syntax is given 1250 by the following ABNF: 1252 TimeSpecification = "{" sp ts-time 1253 [ "," sp ts-notThisTime ] 1254 [ "," sp ts-timeZone ] 1255 sp "}" 1257 ts-time = id-time msp TSTime 1258 ts-notThisTime = id-notThisTime msp BOOLEAN 1259 ts-timeZone = id-timeZone msp TimeZone 1260 id-time = %x74.69.6D.65 ; "time" 1261 id-notThisTime = %x6E.6F.74.54.68.69.73.54.69.6D.65 ; "notThisTime" 1262 id-timeZone = %x74.69.6D.65.5A.6F.6E.65 ; "timeZone" 1264 TSTime = tst-absolute / tst-periodic 1265 tst-absolute = id-absolute ":" AbsoluteTime 1266 tst-periodic = id-periodic ":" Periods 1267 AbsoluteTime = "{" [ sp at-startTime ] 1268 [ sep sp at-endTime ] 1269 sp "}" 1270 at-startTime = id-startTime msp GeneralizedTime 1271 at-endTime = id-endTime msp GeneralizedTime 1272 id-startTime = %x73.74.61.72.74.54.69.6D.65 ; "startTime" 1273 id-endTime = %x65.6E.64.54.69.6D.65 ; "endTime" 1275 Periods = "{" [ sp Period *( "," sp Period ) ] sp "}" 1276 Period = "{" [ sp p-timesOfDay ] 1277 [ sep sp p-days ] 1278 [ sep sp p-weeks ] 1279 [ sep sp p-months ] 1280 [ sep sp p-years ] 1281 sp "}" 1283 p-timesOfDay = id-timesOfDay msp DayTimeBands 1284 p-days = id-days msp Days 1285 p-weeks = id-weeks msp Weeks 1286 p-months = id-months msp Months 1287 p-years = id-years msp Years 1288 id-timesOfDay = %x74.69.6D.65.73.4F.66.44.61.79 ; "timesOfDay" 1289 id-days = %x64.61.79.73 ; "days" 1290 id-weeks = %x77.65.65.6B.73 ; "weeks" 1291 id-months = %x6D.6F.6E.74.68.73 ; "months" 1292 id-years = %x79.65.61.72.73 ; "years" 1294 DayTimeBands = "{" sp DayTimeBand *( "," sp DayTimeBand ) sp "}" 1295 DayTimeBand = "{" [ sp dtb-startDayTime ] 1296 [ sep sp dtb-endDayTime ] 1297 sp "}" 1298 dtb-startDayTime = id-startDayTime msp DayTime 1299 dtb-endDayTime = id-endDayTime msp DayTime 1300 id-startDayTime = %x73.74.61.72.74.44.61.79.54.69.6D.65 1301 ; "startDayTime" 1302 id-endDayTime = %x65.6E.64.44.61.79.54.69.6D.65 ; "endDayTime" 1304 DayTime = "{" sp dt-hour 1305 [ "," sp dt-minute ] 1306 [ "," sp dt-second ] 1307 sp "}" 1308 dt-hour = id-hour msp INTEGER ; 0 to 23 1309 dt-minute = id-minute msp INTEGER ; 0 to 59 1310 dt-second = id-second msp INTEGER ; 0 to 59 1311 id-hour = %x68.6F.75.72 ; "hour" 1312 id-minute = %x6D.69.6E.75.74.65 ; "minute" 1313 id-second = %x73.65.63.6F.6E.64 ; "second" 1315 Days = days-intDay / days-bitDay / days-dayOf 1316 days-intDay = id-intDay ":" SET-OF-INTEGER 1317 days-bitDay = id-bitDay ":" BitDay 1318 days-dayOf = id-dayOf ":" XDayOf 1319 id-intDay = %x69.6E.74.44.61.79 ; "intDay" 1320 id-bitDay = %x62.69.74.44.61.79 ; "bitDay" 1321 id-dayOf = %x64.61.79.4F.66 ; "dayOf" 1323 SET-OF-INTEGER = "{" [ sp INTEGER *( "," sp INTEGER ) ] "}" 1325 BitDay = BIT-STRING / day-bit-list 1326 day-bit-list = "{" [ sp day *( "," sp day ) ] sp "}" 1327 day = %x73.75.6E.64.61.79 ; "sunday" 1328 / %x6D.6F.6E.64.61.79 ; "monday" 1329 / %x74.75.65.73.64.61.79 ; "tuesday" 1330 / %x77.65.64.6E.65.73.64.61.79 ; "wednesday" 1331 / %x74.68.75.72.73.64.61.79 ; "thursday" 1332 / %x66.72.69.64.61.79 ; "friday" 1333 / %x73.61.74.75.72.64.61.79 ; "saturday" 1335 XDayOf = xdo-first / xdo-second / xdo-third / xdo-fourth / xdo-fifth 1337 xdo-first = id-first ":" NamedDay 1338 xdo-second = id-second ":" NamedDay 1339 xdo-third = id-third ":" NamedDay 1340 xdo-fourth = id-fourth ":" NamedDay 1341 xdo-fifth = id-fifth ":" NamedDay 1343 NamedDay = nd-intNamedDays / nd-bitNamedDays 1344 nd-intNamedDays = id-intNamedDays ":" day 1345 nd-bitNamedDays = id-bitNamedDays ":" ( BIT-STRING / day-bit-list ) 1346 id-intNamedDays = %x69.6E.74.4E.61.6D.65.64.44.61.79.73 1347 ; "intNamedDays" 1348 id-bitNamedDays = %x62.69.74.4E.61.6D.65.64.44.61.79.73 1349 ; "bitNamedDays" 1351 Weeks = weeks-allWeeks / weeks-intWeek / weeks-bitWeek 1352 weeks-allWeeks = id-allWeeks ":" NULL 1353 weeks-intWeek = id-intWeek ":" SET-OF-INTEGER 1354 weeks-bitWeek = id-bitWeek ":" BitWeek 1355 id-allWeeks = %x61.6C.6C.57.65.65.6B.73 ; "allWeeks" 1356 id-intWeek = %x69.6E.74.57.65.65.6B ; "intWeek" 1357 id-bitWeek = %x62.69.74.57.65.65.6B ; "bitWeek" 1358 BitWeek = BIT-STRING / week-bit-list 1359 week-bit-list = "{" [ sp week-bit *( "," sp week-bit ) ] sp "}" 1360 week-bit = %x77.65.65.6B.31 ; "week1" 1361 / %x77.65.65.6B.32 ; "week2" 1362 / %x77.65.65.6B.33 ; "week3" 1363 / %x77.65.65.6B.34 ; "week4" 1364 / %x77.65.65.6B.35 ; "week5" 1366 Months = months-allMonths / months-intMonth / months-bitMonth 1368 months-allMonths = id-allMonths ":" NULL 1369 months-intMonth = id-intMonth ":" SET-OF-INTEGER 1370 months-bitMonth = id-bitMonth ":" BitMonth 1371 id-allMonths = %x61.6C.6C.4D.6F.6E.74.68.73 ; "allMonths" 1372 id-intMonth = %x69.6E.74.4D.6F.6E.74.68 ; "intMonth" 1373 id-bitMonth = %x62.69.74.4D.6F.6E.74.68 ; "bitMonth" 1374 BitMonth = BIT-STRING / month-bit-list 1375 month-bit-list = "{" [ sp month-bit *( "," sp month-bit ) ] sp "}" 1376 month-bit = %x6A.61.6E.75.61.72.79 ; "january" 1377 / %x66.65.62.72.75.61.72.79 ; "february" 1378 / %x6D.61.72.63.68 ; "march" 1379 / %x61.70.72.69.6C ; "april" 1380 / %x6D.61.79 ; "may" 1381 / %x6A.75.6E.65 ; "june" 1382 / %x6A.75.6C.79 ; "july" 1383 / %x61.75.67.75.73.74 ; "august" 1384 / %x22.73.65.70.74.65.6D.62.65.72 ; "september" 1385 / %x6F.63.74.6F.62.65.72 ; "october" 1386 / %x6E.6F.76.65.6D.62.65.72 ; "november" 1387 / %x64.65.63.65.6D.62.65.72 ; "december" 1389 Years = "{" [ sp Year *( "," sp Year ) ] sp "}" 1390 Year = INTEGER ; must be >= 1000 1392 TimeZone = INTEGER ; -12 to 12 1394 The rule is given in [16]. 1396 8.8 Acceptable Certificate Policies Match 1398 Acceptable Certificate Policies Match is described in section 15.5.2.3.1 1399 of [9]. The string description of the acceptableCertPoliciesMatch 1400 matching rule is: 1402 ( 2.5.13.59 NAME 'acceptableCertPoliciesMatch' 1403 SYNTAX 1.2.826.0.1.3344810.7.17) 1405 The syntax definition is: 1407 (1.2.826.0.1.3344810.7.17 DESC 'Acceptable Certificate Policies Syntax) 1409 The ASN.1 for AcceptableCertPoliciesSyntax is defined in 15.5.2.3 of 1410 [9], as are the semantics of its components. 1412 The LDAP string encoding of an assertion value of this syntax is given 1413 by the following ABNF: 1415 AcceptableCertPoliciesSyntax = "{" sp CertPolicyId 1416 *( "," sp CertPolicyId ) sp "}" 1418 8.9 Attribute Descriptor Match 1420 Attribute Descriptor Match is described in section 15.3.2.2.1 of [9]. 1421 The string description of the attDescriptor matching rule is: 1423 ( 2.5.13.58 NAME 'attDescriptor' 1424 SYNTAX 1.2.826.0.1.3344810.7.18) 1426 The syntax definition is: 1428 (1.2.826.0.1.3344810.7.18 DESC 'Attribute Descriptor Syntax') 1430 The ASN.1 for AttributeDescriptorSyntax is defined in 15.3.2.2 of [9], 1431 as are the semantics of its components. 1433 The LDAP string encoding of an assertion value of this syntax is given 1434 by the following ABNF: 1436 AttributeDescriptorSyntax = "{" sp ads-identifier 1437 "," sp ads-attributeSyntax 1438 [ "," sp ads-name ] 1439 [ "," sp ads-description ] 1440 "," sp ads-dominationRule 1441 sp "}" 1443 ads-identifier = id-identifier msp AttributeIdentifier 1444 ads-attributeSyntax = id-attributeSyntax msp AttributeSyntax 1445 ads-name = id-name msp AttributeName 1446 ads-description = id-description msp AttributeDescription 1447 ads-dominationRule = id-dominationRule msp PrivilegePolicyIdentifier 1448 id-identifier = %x69.64.65.6E.74.69.66.69.65.72 ; "identifier" 1449 id-attributeSyntax = %x61.74.74.72.69.62.75.74.65.53.79.6E.74.61.78 1450 ; "attributeSyntax" 1451 id-name = %x6E.61.6D.65 ; "name" 1452 id-description = %x64.65.73.63.72.69.70.74.69.6F.6E 1453 ; "description" 1454 id-dominationRule = %x64.6F.6D.69.6E.61.74.69.6F.6E.52.75.6C.65 1455 ; "dominationRule" 1457 AttributeSyntax = OCTET-STRING ; an empty string is not allowed 1458 AttributeIdentifier = AttributeType 1459 AttributeName = UTF8String ; an empty string is not allowed 1460 AttributeDescription = UTF8String ; an empty string is not allowed 1462 PrivilegePolicyIdentifier = "{" sp ppi-privilegePolicy "," 1463 sp ppi-privPolSyntax 1464 sp "}" 1466 ppi-privilegePolicy = id-privilegePolicy msp PrivilegePolicy 1467 ppi-privPolSyntax = id-privPolSyntax msp InfoSyntax 1468 id-privilegePolicy = %x70.72.69.76.69.6C.65.67.65.50.6F.6C.69.63.79 1469 ; "privilegePolicy" 1470 id-privPolSyntax = %x70.72.69.76.50.6F.6C.53.79.6E.74.61.78 1471 ; "privPolSyntax" 1473 PrivilegePolicy = OBJECT-IDENTIFIER 1475 InfoSyntax = is-content / is-pointer 1476 is-content = id-content ":" DirectoryString 1477 is-pointer = id-pointer ":" InfoSyntaxPointer 1478 id-content = %x63.6F.6E.74.65.6E.74 ; "content" 1479 id-pointer = %x70.6F.69.6E.74.65.72 ; "pointer" 1481 InfoSyntaxPointer = "{" sp isp-name 1482 [ "," sp isp-hash ] 1483 sp "}" 1485 isp-name = id-name msp GeneralNames 1486 isp-hash = id-hash msp HASH 1487 id-hash = %x68.61.73.68 ; "hash" 1488 HASH = "{" sp h-algorithmIdentifier "," 1489 sp h-hashValue 1490 sp "}" 1492 h-algorithmIdentifier = id-algorithmIdentifier msp AlgorithmIdentifier 1493 h-hashValue = id-hashValue msp BIT-STRING 1495 id-algorithmIdentifier = %x61.6C.67.6F.72.69.74.68.6D.49.64.65.6E.74 1496 %x69.66.69.65.72 ; "algorithmIdentifier" 1497 id-hashValue = %x68.61.73.68.56.61.6C.75.65 ; "hashValue" 1499 The rule is given in [16]. 1501 8.10 Source of Authority Match 1503 Note. This rule has not been defined by X.509, but this is perhaps an 1504 omission that should be rectified. It is an easy matching rule to 1505 define since it has a null syntax i.e. we will be matching on whether 1506 the extension is present or not. 1508 Source of Authority Match returns TRUE if an attribute certificate 1509 contains an SOA Identifier extension. The SOA Identifier extension is 1510 described in section 15.3.2.1 of [9]. The string description of the 1511 sOAIdentifierMatch matching rule is: 1513 ( 2.5.13.x NAME 'sOAIdentifierMatch' 1514 SYNTAX 1.2.36.79672281.1.5.1) 1516 The syntax definition of 1.2.36.79672281.1.5.1 (NULL) is given in [13]. 1518 9 PMI Object Classes 1520 The definitions of the PMI directory object classes can be found in 1521 section 17.1 of [9]. They are repeated here for the convenience of the 1522 reader. 1524 pmiUser OBJECT-CLASS ::= { 1525 -- a privilege holder 1526 SUBCLASS OF {top} 1527 KIND auxiliary 1528 MAY CONTAIN {attributeCertificateAttribute} 1529 ID { joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser (24) } } 1531 pmiAA OBJECT-CLASS ::= { 1532 -- an attribute authority 1533 SUBCLASS OF {top} 1534 KIND auxiliary 1535 MAY CONTAIN {aACertificate | 1536 attributeCertificateRevocationList | 1537 attributeAuthorityRevocationList} 1538 ID { joint-iso-ccitt(2) ds(5) objectClass(6) pmiAA (25) } } 1540 pmiSOA OBJECT-CLASS ::= { 1541 -- a PMI Source of Authority 1542 SUBCLASS OF {top} 1543 KIND auxiliary 1544 MAY CONTAIN {attributeCertificateRevocationList | 1545 attributeAuthorityRevocationList | 1546 attributeDescriptorCertificate} 1547 ID { joint-iso-ccitt(2) ds(5) objectClass(6) pmiSOA (26) } } 1549 attCertCRLDistributionPt OBJECT-CLASS ::= { 1550 -- an AC CRL distribution point 1551 SUBCLASS OF {top} 1552 KIND auxiliary 1553 MAY CONTAIN { attributeCertificateRevocationList | 1554 attributeAuthorityRevocationList } 1555 ID { joint-iso-ccitt(2) ds(5) objectClass(6) 1556 attCertCRLDistributionPts (27) } } 1558 pmiDelegationPath OBJECT-CLASS ::= { 1559 -- an object that may contain a delegation path 1560 SUBCLASS OF {top} 1561 KIND auxiliary 1562 MAY CONTAIN { delegationPath } 1563 ID { joint-iso-ccitt(2) ds(5) objectClass(6) delegationPath (33) } } 1565 privilegePolicy OBJECT-CLASS ::= { 1566 -- an object that may contain privilege policy information 1567 SUBCLASS OF {top} 1568 KIND auxiliary 1569 MAY CONTAIN {privPolicy } 1570 ID { joint-iso-ccitt(2) ds(5) objectClass(6) privilegePolicy (32) } } 1572 10. Security Considerations 1574 This [Internet Draft/Standard] describes the schema for the storage 1575 and matching of attribute certificates and revocation lists in an 1576 LDAP directory server. It does not address the protocol for the 1577 retrieval of this information. 1579 LDAP servers SHOULD use access control information to protect the 1580 information during its storage. In addition, clients MAY choose to 1581 encrypt the attributes in the attribute certificates before storing 1582 them in an LDAP server. 1584 11. References 1586 [1] Bradner, S. The Internet Standards Process -- Revision 3. RFC 1587 2026 October 1996. 1589 [2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access 1590 Protocol", RFC 1777, March 1995. 1592 [3] K. Dally. "A Summary of the X.500(3rd edition) User Schema for use 1593 with LDAPv3", 1595 [4] J. Sermersheim "Lightweight Directory Access Protocol (v3)" July 2001 1598 [5] S.Bradner. "Key words for use in RFCs to Indicate Requirement 1599 Levels", RFC 2119, March 1997. 1601 [6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access 1602 Protocol (v3): UTF-8 String Representation of Distinguished Names", 1603 RFC2253, December 1997. 1605 [7] K. Dally "Lightweight Directory Access Protocol (v3): Attribute 1606 Syntax Definitions", , June 2001 1608 [8] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key 1609 Infrastructure, LDAPv2 Schema", RFC 2587, June 1999 1611 [9] ITU-T Rec. X.509(2000) The Directory: Authentication 1612 Framework 1614 [10] D. Crocker, P. Overell, "Augmented BNF for Syntax 1615 Specifications: ABNF", RFC 2234, November 1997 1617 [11] S. Kille, "MIXER (Mime Internet X.400 Enhanced Relay): 1618 Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998 1620 [12] Howes, T., Kille, S., Yeong, W., Robbins, C., "The String 1621 Representation of Standard Attribute Syntaxes", RFC 1778, March 1995 1623 [13] S. Legg, "LDAP & X.500 Component Matching Rules", , November 2001, a work in progress 1626 [14] R. Housley, W. Ford, W Polk, D. Solo. "Internet X.509 Public Key 1627 Infrastructure - Certificate and CRL Profile" , July 2001 1630 [15] ITU-T Rec. X.520(2000) The Directory: Selected Attribute Types 1632 [16] S. Legg, "Common Elements of GSER Encodings", , November 2001, a work in progress 1635 12. Intellectual Property Notice 1637 The IETF takes no position regarding the validity or scope of any 1638 intellectual property or other rights that might be claimed to 1639 pertain to the implementation or use of the technology described in 1640 this document or the extent to which any license under such rights 1641 might or might not be available; neither does it represent that it has 1642 made any effort to identify any such rights. 1643 Information on the 1644 IETF's procedures with respect to rights in standards-track and 1645 standards-related documentation can be found in BCP-11. [BCP-11] 1646 Copies of claims of rights made available for publication and any 1647 assurances of licenses to be made available, or the result of an 1648 attempt made to obtain a general license or permission for the use of 1649 such proprietary rights by implementors or users of this specification 1650 can be obtained from the IETF Secretariat. 1652 The IETF invites any interested party to bring to its attention any 1653 copyrights, patents or patent applications, or other proprietary 1654 rights which may cover technology that may be required to practice 1655 this standard. 1656 Please address the information to the IETF Executive 1657 Director. 1659 13. Copyright 1661 Copyright (C) The Internet Society (2001). All Rights Reserved. 1663 This document and translations of it may be copied and furnished to 1664 others, and derivative works that comment on or otherwise explain it 1665 or assist in its implementation may be prepared, copied, published 1666 and distributed, in whole or in part, without restriction of any 1667 kind, provided that the above copyright notice and this paragraph are 1668 included on all such copies and derivative works. However, this 1669 document itself may not be modified in any way, such as by removing 1670 the copyright notice or references to the Internet Society or other 1671 Internet organizations, except as needed for the purpose of 1672 developing Internet standards in which case the procedures for 1673 copyrights defined in the Internet Standards process must be 1674 followed, or as required to translate it into languages other than 1675 English. 1677 The limited permissions granted above are perpetual and will not be 1678 revoked by the Internet Society or its successors or assigns. 1680 This document and the information contained herein is provided on an 1681 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1682 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1683 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1684 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1685 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1687 14. Authors' Addresses 1689 David Chadwick 1690 IS Institute 1691 University of Salford 1692 Salford 1693 England 1694 M5 4WT 1696 Email: d.w.chadwick@salford.ac.uk 1698 Steven Legg 1699 Adacel Technologies Ltd. 1700 405-409 Ferntree Gully Road, 1701 Mount Waverley, 1702 Victoria, 3149 1703 Australia 1705 Email: steven.legg@adacel.com.au 1707 15. Changes 1709 From Version 00 1711 i) Added ABNF notation for all of the syntaxes. 1713 ii) Removed the restriction on the syntax of Distribution Point Names. 1715 iii) Removed constraints on IssuerSerial. 1717 iv) Bug detected in X.509 AttributeCertificateExactMatch that will need 1718 resolving. 1720 v) Changed the string encodings for non-exact matches to keywords for 1721 each component instead of $ separators. 1723 From Version 01 1725 i) Added and corrected all X.509 PKI schema definitions, since these 1726 have been removed from RFC2252-bis. 1727 ii) Changed assertion syntaxes to use the syntax defined by Component 1728 Matching Rules 1729 iii) Included all the matching rules for AC extensions 1731 16. Outstanding Issues 1733 i. We need to decide if userSMIMECertificates should also be 1734 supported as part of this profile or not. 1735 ii. Should we obsolete RFC 2587 and copy relevant schema into this 1736 document, or continue to reference it. 1737 iii. Should the PMI schema be put in a separate document, so that the 1738 PKI schema can progress at a faster rate? One reason for 1739 separating them is that Matched Values and LDAPv3 Profile 1740 reference this ID. 1741 iv. There is still a bug in the X.509 1742 AttributeCertificateExactAssertion. It reads: 1744 AttributeCertificateExactAssertion ::= SEQUENCE { 1745 serialNumber CertificateSerialNumber OPTIONAL, 1746 issuer IssuerSerial } 1747 OPTIONAL should be removed from the serialNumber. IssuerSerial should be 1748 replaced by AttCertIssuer. This ID has assumed that the change will be 1749 made. 1751 v. Should the AttributeType in Attribute Certificate Match allow the 1752 LDAP encoding option for describing attribute type OIDs 1753 (i.e. user friendly names instead of object identifiers)? Note 1754 that attribute names are not guaranteed to be unique, whereas OIDs 1755 are. 1757 17. Table of Contents 1759 1. Introduction 1 1760 2. Subschema Publishing 2 1761 3. Public Key Certificate and CRL Attributes and Syntaxes 2 1762 3.1 userCertificate Attribute 2 1763 3.2 cACertificate Attribute 2 1764 3.3 Certificate Syntax 2 1765 3.4 authorityRevocationList Attribute 3 1766 3.5 certificateRevocationList Attribute 3 1767 3.6 deltaRevocationList Attribute 3 1768 3.7 Certificate List Syntax 3 1769 3.8 crossCertificatePair Attribute 4 1770 3.9 Certificate Pair Syntax 4 1771 4. Public Key Certificate Matching Rules and Assertion Syntaxes 4 1772 4.1 Certificate Exact Match 5 1773 4.2 Certificate Match 6 1774 4.3 Certificate Pair Exact Match 10 1775 4.4 Certificate Pair Match 11 1776 5 Certificate Revocation List Matching Rules 11 1777 5.1 Certificate List Exact Match 11 1778 5.2 Certificate List Match 12 1779 6. Privilege Management Attribute Certificate and CRL Attributes and 1780 Syntaxes 14 1781 6.1 Attribute Certificate Attribute 14 1782 6.2 Attribute Authority Certificate Attribute 14 1783 6.3 Attribute Descriptor Certificate Attribute 14 1784 6.4 Attribute Certificate Syntax 15 1785 6.5 Attribute Certificate Revocation List Attribute 15 1786 6.6 Attribute Authority Certificate Revocation List Attribute 15 1787 7 PMI Matching Rules 15 1788 7.1 Attribute Certificate Exact Match 16 1789 7.2 Attribute Certificate Match 18 1790 8 AC Extensions Matching Rules 19 1791 8.1 Holder Issuer Match 19 1792 8.2 Delegation Path Match 20 1793 8.3 Authority Attribute Identifier Match 20 1794 8.4 Role Specification Certificate Identifier Match 21 1795 8.5 Basic Attribute Constraints Match 21 1796 8.6 Delegated Name Constraints Match 22 1797 8.7 Time Specification Match 22 1798 8.8 Acceptable Certificate Policies Match 25 1799 8.9 Attribute Descriptor Match 25 1800 8.10 Source of Authority Match 27 1801 9 PMI Object Classes 27 1802 10. Security Considerations 28 1803 11. References 28 1804 12. Intellectual Property Notice 29 1805 13. Copyright 29 1806 14. Authors' Addresses 30 1807 15. Changes 30 1808 16. Outstanding Issues 31