INTERNET-DRAFT D. W. Chadwick
PKIX WG University of Salford
Intended Category: Standards Track S. Legg
Adacel Technologies
Expires on 27 December 2002 27 June 2002
Internet X.509 Public Key Infrastructure
LDAP Schema and Syntaxes for PMIs
<draft-ietf-pkix-ldap-pmi-schema-00.txt>
Copyright (C) The Internet Society (2002). All Rights Reserved.
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all the provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Comments and suggestions on this document are encouraged. Comments on
this document should be sent to the PKIX working group discussion list
<ietf-pkix@imc.org> or directly to the authors.
ABSTRACT
This document describes LDAP schema features that are needed to support
X.509 Privilege Management Infrastructures. Specifically, X.509
attribute types, object classes, matching rules, attribute value
syntaxes and attribute value assertion syntaxes needed for PMIs are
defined.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
1. Introduction
LDAPv3 [4] servers are a natural repository for X.509 PMI components
e.g. attribute certificate attributes, attribute certificate revocation
lists and attribute authority entries. This [document/ID/standard]
defines the LDAP subschema needed for storing X.509 PMI information in
LDAPv3 servers and for accessing this information e.g. searching for it,
updating it, and perform comparisons on it.
2. Subschema Publishing
LDAPv3 allows the subschema supported by a server to be published in a
subschema subentry. Clients following this profile which support the
Search operation containing an extensible matching rule SHOULD use the
subschemaSubentry attribute in the root DSE to find the
subschemaSubentry, and SHOULD use the matchingRule and matchingRuleUse
operational attributes in the subschema subentry in order to determine
whether the server supports the various matching rules described below.
Servers that support extensible matching SHOULD publish the matching
rules they support in the matchingRule and matchingRuleUse operational
attributes.
3. PMI Attributes and Syntaxes
LDAP servers MAY store any type of PMI attribute, and LDAP clients MAY
request them to be returned by adding them to the Search Request
AttributeDescriptionList (either explicitly or implicity via requesting
all user attributes).
3.1 Attribute Certificate Attribute
The attributeCertificateAttribute is defined in 17.2.1 of [9]. It is
used to hold the attribute certificates of a user. The LDAPspecific
encoding for values of this attribute is described in section 3.4.
attributeCertificateAttribute ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4)
attributeCertificate(58) } }
The corresponding LDAP description is
( 2.5.4.58 NAME 'attributeCertificateAttribute'
EQUALITY attributeCertificateExactMatch
SYNTAX 1.2.826.0.1.3344810.7.5 )
3.2 Attribute Authority Certificate Attribute
The attribute authority attribute certificate is defined in 17.2.2 of
[9]. The aAcertificate attribute holds the privileges of an attribute
authority. The LDAPspecific encoding for values of this attribute is
described in section 3.4.
aACertificate ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4)
aACertificate(61) } }
The corresponding LDAP description is
( 2.5.4.61 NAME 'aACertificate'
EQUALITY attributeCertificateExactMatch
SYNTAX 1.2.826.0.1.3344810.7.5 )
3.3 Attribute Descriptor Certificate Attribute
The attributeDescriptorCertificate attribute is defined in 17.2.3 of
[9]. The certificate is self signed by a source of authority and holds a
description of the privilege and its delegation rules. The LDAPspecific
encoding for values of this attribute is described in section 3.4.
attributeDescriptorCertificate ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4)
attributeDescriptorCertificate (62) } }
The corresponding LDAP description is
( 2.5.4.62 NAME 'attributeDescriptorCertificate'
EQUALITY attributeCertificateExactMatch
SYNTAX 1.2.826.0.1.3344810.7.5 )
3.4 Attribute Certificate Syntax
The LDAP-specific encoding for a certificate value is the octet string
that results from BER/DER-encoding an X.509 attribute certificate. The
following string states the OID assigned to this syntax:
(1.2.826.0.1.3344810.7.5 DESC 'Attribute Certificate' )
Servers MUST preserve values in this syntax exactly as given when
storing and retrieving them. Transformation of these values between
storage and retrieval MUST NOT take place.
3.5 Attribute Certificate Revocation List Attribute
The attributeCertificateRevocationList attribute is defined in section
17.2.4 of [9]. It holds a list of attribute certificates that have been
revoked. The LDAP-specific encoding for values of this attribute is
described in [2].
attributeCertificateRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) } }
The corresponding LDAP description is
( 2.5.4.59 NAME 'attributeCertificateRevocationList'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
3.6 Attribute Authority Certificate Revocation List Attribute
The attribute authority certificate revocation list attribute is defined
in section 17.2.5 of [9]. It holds a list of AA certificates that have
been revoked. The LDAP-specific encoding for values of this attribute is
described in [2].
attributeAuthorityRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) } }
The corresponding LDAP description is
( 2.5.4.63 NAME 'attributeAuthorityRevocationList'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
3.7 Delegation Path Attribute
The delegation path attribute contains delegation paths, each consisting
of a sequence of attribute certificates
delegationPath ATTRIBUTE ::= {
WITH SYNTAX AttCertPath
ID ( joint-iso-ccitt(2) ds(5) attributeType(4) delPath (73) } )
AttCertPath ::= SEQUENCE OF AttributeCertificate
The corresponding LDAP description is
( 2.5.4.73 NAME 'delegationPath'
SYNTAX 1.2.826.0.1.3344810.7.21 )
The following description is copied from X.509 (2000) [9].
"This attribute can be stored in the AA directory entry and would
contain some delegation paths from that AA to other AAs. This attribute,
if used, enables more efficient retrieval of delegated attribute
certificates that form frequently used delegation paths. As such, there
are no specific requirements for this attribute to be used and the set
of values that are stored in the attribute is unlikely to represent the
complete set of delegation paths for any given AA."
3.8 Delegation Path Syntax
The LDAP-specific encoding for a delegation path value is the octet
string that results from the BER/DER-encoding of a sequence of attribute
certificates. The following string states the OID assigned to this
syntax:
( 1.2.826.0.1.3344810.7.21 DESC 'Attribute certificate delegation
path' )
Servers MUST preserve values in this syntax exactly as given when
storing and retrieving them.
4 PMI Matching Rules
LDAP servers that support the storage of attributes with the
AttributeCertificate syntax MUST support searching for entries
containing specific attribute certificates, via the
attributeCertificateExactMatch matching rule.
LDAPv3Servers MAY support flexible matching for any attributes with the
AttributeCertificate syntax via the attributeCertificateMatch matching
rule or any of the matching rules defined for the certificate
extensions. LDAPv3 servers SHOULD publish the matching rules that they
do support in the matchingRule and matchingRuleUse operational
attributes of the subschema subentry. If the server does support
flexible matching (either via attributeCertificateMatch or some other
matching rule), then the extensibleMatch filter of the Search request
MUST be supported. LDAPv3 clients MAY support the extensibleMatch
filter of the Search operation, along one or more of the optional
elements of attributeCertificateMatch or any of the certificate
extension matching rules.
The LDAP-specific (i.e. string) encodings for the assertion syntaxes
defined in this document are specified by the Generic String Encoding
Rules (GSER) [3]. The ABNF in this document for these assertion syntaxes
is provided only as a convenience and is equivalent to the encoding
specified by the application of [3]. (The only exception to this is the
alternative simple endoding for attributeCertificatExactMatch.) Since
the associated ASN.1 types for the assertion syntaxes described here may
be extended in future editions of X.509 [9], the provided ABNF should be
regarded as a snapshot in time. The LDAP-specific encoding for any
extension to a syntax's underlying ASN.1 type can be determined from
[3]. In the event that there is a discrepancy between the ABNF in this
document and the encoding determined by [3], [3] is to be taken as
definitive.
4.1 Attribute Certificate Exact Match
The equality matching rule for all types of attribute with
AttributeCertificate syntax is the attributeCertificateExactMatch,
This is defined in 17.3.1 of [9]. It is reproduced below for the
convenience of the reader (but see Outstanding Issues).
attributeCertificateExactMatch MATCHING-RULE ::= {
SYNTAX AttributeCertificateExactAssertion
ID { joint-iso-ccitt(2) ds(5) mr (13)
attributeCertificateExactMatch (45) } }
AttributeCertificateExactAssertion ::= SEQUENCE {
serialNumber CertificateSerialNumber,
issuer AttCertIssuer }
CertificateSerialNumber ::= INTEGER
AttCertIssuer ::= [0] SEQUENCE {
issuerName GeneralNames OPTIONAL,
baseCertificateID [0] IssuerSerial OPTIONAL,
objectDigestInfo [1] ObjectDigestInfo OPTIONAL }
-- At least one component shall be present
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL }
UniqueIdentifier ::= BIT STRING
ObjectDigestInfo ::= SEQUENCE {
digestedObjectType ENUMERATED {
publicKey (0),
publicKeyCert (1),
otherObjectTypes (2) },
otherObjectTypeID OBJECT IDENTIFIER OPTIONAL,
digestAlgorithm AlgorithmIdentifier,
objectDigest BIT STRING }
The LDAP definition for the above matching rule is:
( 2.5.13.45 NAME 'attributeCertificateExactMatch'
SYNTAX 1.2.826.0.1.3344810.7.6)
The syntax definition is:
(1.2.826.0.1.3344810.7.6 DESC 'Attribute certificate exact
assertion (serial number and issuer details)' )
The LDAP-specific encoding of an assertion value of this syntax is a
choice between
- the GSER encoding <GSERAttributeCertificateExactAssertion> defined by
[3] and
- the simple encoding <SimpleCertificateExactAssertion> defined in [2].
The full syntax is described by the following Augmented BNF [10]:
AttributeCertificateExactAssertion =
GSERAttributeCertificateExactAssertion /
SimpleCertificateExactAssertion
GSERAttributeCertificateExactAssertion = "{" sp acea-serialNumber ","
sp acea-issuer
sp "}"
acea-serialNumber = id-serialNumber msp CertificateSerialNumber
acea-issuer = id-issuer msp AttCertIssuer
id-serialNumber = %x73.65.72.69.61.6C.4E.75.6D.62.65.72
; "serialNumber"
id-issuer = %x69.73.73.75.65.72 ; "issuer"
AttCertIssuer = "{" [ sp aci-issuerName ]
[ sep sp aci-baseCertificateID ]
[ sep sp aci-objectDigestInfo ]
sp "}"
At least one of <aci-issuerName>, <aci-baseCertificateID> or
<aci-objectDigestInfo> MUST be present.
aci-issuerName = id-issuerName msp GeneralNames
aci-baseCertificateID = id-baseCertificateID msp IssuerSerial
aci-objectDigestInfo = id-objectDigestInfo msp ObjectDigestInfo
id-issuerName = %x69.73.73.75.65.72.4E.61.6D.65
; "issuerName"
GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}"
GeneralName = gn-otherName
/ gn-rfc822Name
/ gn-dNSName
/ gn-x400Address
/ gn-directoryName
/ gn-ediPartyName
/ gn-uniformResourceIdentifier
/ gn-iPAddress
/ gn-registeredID
gn-otherName = id-otherName ":" OtherName
gn-rfc822Name = id-rfc822Name ":" IA5String
gn-dNSName = id-dNSName ":" IA5String
gn-x400Address = id-x400Address ":" ORAddress
gn-directoryName = id-directoryName ":" Name
gn-ediPartyName = id-ediPartyName ":" EDIPartyName
gn-iPAddress = id-iPAddress ":" OCTET-STRING
gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER
gn-uniformResourceIdentifier = id-uniformResourceIdentifier
":" IA5String
id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; "otherName"
id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; "rfc822Name"
id-dNSName = %x64.4E.53.4E.61.6D.65 ; "dNSName"
id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73
; "x400Address"
id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65
; "directoryName"
id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65
; "ediPartyName"
id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; "iPAddress"
id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64
; "registeredId"
id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75
%x72.63.65.49.64.65.6E.74.69.66.69.65
%x72 ; "uniformResourceIdentifier"
gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
; "registeredID"
OtherName = "{" sp on-type-id "," sp on-value sp "}"
on-type-id = id-type-id msp OBJECT-IDENTIFIER
on-value = id-value msp Value
id-type-id = %x74.79.70.65.2D.69.64 ; "type-id"
id-value = %x76.61.6C.75.65 ; "value"
The <Value> rule is defined in [3].
EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}"
nameAssigner = id-nameAssigner msp DirectoryString
partyName = id-partyName msp DirectoryString
id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72
; "nameAssigner"
id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; "partyName"
id-objectDigestInfo = %x6F.62.6A.65.63.74.44.69.67.65.73.74.49.6E
%x66.6F ; "objectDigestInfo"
ObjectDigestInfo = "{" sp odi-digestedObjectType
[ "," sp odi-otherObjectTypeID ]
"," sp odi-digestAlgorithm
"," sp odi-objectDigest
sp "}"
odi-digestedObjectType = id-digestedObjectType msp
DigestedObjectType
odi-otherObjectTypeID = id-otherObjectTypeID msp OBJECT-IDENTIFIER
odi-digestAlgorithm = id-digestAlgorithm msp AlgorithmIdentifier
odi-objectDigest = id-objectDigest msp BIT-STRING
id-digestedObjectType = %x64.69.67.65.73.74.65.64.4F.62.6A.65.63.74
%x54.79.70.65 ; "digestedObjectType"
id-otherObjectTypeID = %x6F.74.68.65.72.4F.62.6A.65.63.74.54.79.70
%x65.49.44 ; "otherObjectTypeID"
id-digestAlgorithm = %x64.69.67.65.73.74.41.6C.67.6F.72.69.74.68
%x6D ; "digestAlgorithm"
id-objectDigest = %x6F.62.6A.65.63.74.44.69.67.65.73.74
; "objectDigest"
DigestedObjectType = id-publicKey
/ id-publicKeyCert
/ id-otherObjectTypes
id-publicKey = %x70.75.62.6C.69.63.4B.65.79 ; "publicKey"
id-publicKeyCert = %x70.75.62.6C.69.63.4B.65.79.43.65.72.74
; "publicKeyCert"
id-otherObjectTypes = %x6F.74.68.65.72.4F.62.6A.65.63.74.54.79.70.65
%x73 ; "otherObjectTypes"
AlgorithmIdentifier = "{" sp ai-algorithm
[ "," sp ai-parameters ]
sp "}"
ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER
ai-parameters = id-parameters msp Value
id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; "algorithm"
id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; "parameters"
IssuerSerial = "{" sp is-issuer
"," sp is-serial
[ "," sp is-issuerUID ]
sp "}"
is-issuer = id-issuer msp GeneralNames
is-serial = id-serial msp CertificateSerialNumber
is-issuerUID = id-issuerUID msp UniqueIdentifier
id-serial = %x73.65.72.69.61.6C ; "serial"
id-issuerUID = %x69.73.73.75.65.72.55.49.44 ; "issuerUID"
UniqueIdentifier = BIT-STRING
4.2 Attribute Certificate Match
Attribute certificate matching rule is defined in section 17.3.2 of
[9]. For the convenience of the reader it is reproduced below:
attributeCertificateMatch MATCHING-RULE ::= {
SYNTAX AttributeCertificateAssertion
ID { joint-iso-ccitt(2) ds(5) mr (13)
attributeCertificateMatch (42) }
AttributeCertificateAssertion ::= SEQUENCE {
holder [0] CHOICE {
baseCertificateID [0] IssuerSerial,
subjectName [1] GeneralNames
} OPTIONAL,
issuer [1] GeneralNames OPTIONAL,
attCertValidity [2] GeneralizedTime OPTIONAL,
attType [3] SET OF AttributeType OPTIONAL }
--At least one component of the sequence must be present
The LDAP definition of the attributeCertificateMatch matching rule
is:
( 2.5.13.42 NAME 'attributeCertificateMatch'
SYNTAX 1.2.826.0.1.3344810.7.7 )
The syntax definition is:
(1.2.826.0.1.3344810.7.7
DESC 'Attribute Certificate Assertion' )
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
AttributeCertificateAssertion = "{" [ sp aca-holder ]
[ sep sp aca-issuer ]
[ sep sp aca-attCertValidity ]
[ sep sp aca-attType ]
sp "}"
aca-holder = id-holder msp ACAHolder
aca-issuer = id-issuer msp GeneralNames
aca-attCertValidity = id-attCertValidity msp GeneralizedTime
aca-attType = id-attType msp SETOFAttributeType
ACAHolder = acah-baseCertificateID / acah-holderName
acah-baseCertificateID = id-baseCertificateID ":" IssuerSerial
acah-holderName = id-holderName ":" GeneralNames
id-baseCertificateID = %x62.61.73.65.43.65.72.74.69.66.69.63.61.74
%x65.49.44 ; "baseCertificateID"
id-holderName = %x68.6F.6C.64.65.72.4E.61.6D.65
; "holderName"
SETOFAttributeType = "{" sp AttributeType
*( "," sp AttributeType ) sp "}"
The <AttributeType> rule is given in [6].
5 AC Extensions Matching Rules
X.509 defines the following matching rules for matching on various
extensions within an attribute certificate.
5.1 Holder Issuer Match
Holder Issuer Match is described in section 17.3.3 of [9]. The string
description of the holderIssuerMatch matching rule is:
( 2.5.13.46 NAME 'holderIssuerMatch'
SYNTAX 1.2.826.0.1.3344810.7.10)
The syntax definition is:
(1.2.826.0.1.3344810.7.10 DESC 'Holder Issuer Assertion' )
The ASN.1 for HolderIssuerAssertion is defined in 17.3.3 of [9], as are
the semantics of its components.
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
HolderIssuerAssertion = "{" [ sp hia-holder ]
[ sep sp hia-issuer ]
sp "}"
hia-holder = id-holder msp Holder
hia-issuer = id-issuer msp AttCertIssuer
Holder = "{" [ sp h-baseCertificateID ]
[ sep sp h-entityName ]
[ sep sp h-objectDigestInfo ]
sp "}"
At least one of <h-baseCertificateID>, <h-entityName> or
<h-objectDigestInfo> MUST be present.
h-baseCertificateID = id-baseCertificateID msp IssuerSerial
h-entityName = id-entityName msp GeneralNames
h-objectDigestInfo = id-objectDigestInfo msp ObjectDigestInfo
id-entityName = %x65.6E.74.69.74.79.4E.61.6D.65 ; "entityName"
5.2 Delegation Path Match
Delegation Path Match is described in section 17.3.4 of [9]. The string
description of the delegationPathMatch matching rule is:
( 2.5.13.61 NAME 'delegationPathMatch'
SYNTAX 1.2.826.0.1.3344810.7.10)
The syntax definition is:
(1.2.826.0.1.3344810.7.10 DESC 'DelMatchSyntax' )
The ASN.1 for DelMatchSyntax is defined in 17.3.4 of [9], as are the
semantics of its components.
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
DelMatchSyntax = "{" sp dms-firstIssuer ","
sp dms-lastHolder
sp "}"
dms-firstIssuer = id-firstIssuer msp AttCertIssuer
dms-lastHolder = id-lastHolder msp Holder
id-firstIssuer = %x66.69.72.73.74.49.73.73.75.65.72 ; "firstIssuer"
id-lastHolder = %x6C.61.73.74.48.6F.6C.64.65.72 ; "lastHolder"
5.3 Authority Attribute Identifier Match
Authority Attribute Identifier Match is described in section 15.5.2.4.1
of [9]. The string description of the authAttIdMatch matching rule is:
( 2.5.13.53 NAME 'authAttIdMatch'
SYNTAX 1.2.826.0.1.3344810.7.12)
The syntax definition is:
(1.2.826.0.1.3344810.7.12 DESC 'Authority Attribute Identifier
Syntax' )
The ASN.1 for AuthorityAttributeIdentifierSyntax is defined in 15.5.2.4
of [9], as are the semantics of its components.
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
AuthorityAttributeIdentifierSyntax = "{" sp AuthAttId
*( "," sp AuthAttId ) sp "}"
AuthAttId = IssuerSerial
5.4 Role Specification Certificate Identifier Match
Role Specification Certificate Identifier match is described in section
15.4.2.1.1 of [9]. The string description of the roleSpecCertIdMatch
Match matching rule is:
( 2.5.13.54 NAME 'roleSpecCertIdMatch '
SYNTAX 1.2.826.0.1.3344810.7.13)
The syntax definition is:
(1.2.826.0.1.3344810.7.13 DESC 'Role Specification Ceritificate
Identifier Syntax' )
The ASN.1 for RoleSpecCertIdentifierSyntax is defined in 15.4.2.1 of
[9], as are the semantics of its components.
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
RoleSpecCertIdentifierSyntax = "{" sp RoleCertSpecIdentifier
*( "," sp RoleCertSpecIdentifier ) sp "}"
RoleCertSpecIdentifier = "{" sp rsci-roleName
"," sp rsci-roleCertIssuer
[ "," sp rsci-roleCertSerialNumber ]
[ "," sp rsci-roleCertLocator ]
sp "}"
rsci-roleName = id-roleName msp GeneralName
rsci-roleCertIssuer = id-roleCertIssuer msp GeneralName
rsci-roleCertSerialNumber = id-roleCertSerialNumber msp
CertificateSerialNumber
rsci-roleCertLocator = id-roleCertLocator msp GeneralName
id-roleName = %x72.6F.6C.65.4E.61.6D.65 ; "roleName"
id-roleCertIssuer = %x72.6F.6C.65.43.65.72.74.49.73.73.75.65
%x72 ; "roleCertIssuer"
id-roleCertSerialNumber = %x72.6F.6C.65.43.65.72.74.53.65.72.69.61
%x6C.4E.75.6D.62.65.72
; "roleCertSerialNumber"
id-roleCertLocator = %x72.6F.6C.65.43.65.72.74.4C.6F.63.61.74
%x6F.72 ; "roleCertLocator"
5.5 Basic Attribute Constraints Match
Basic Attribute Constraints Match is described in section 15.5.2.1.1 of
[9]. The string
description of the holderIssuerMatch matching rule is:
( 2.5.13.55 NAME ' basicAttConstraintsMatch '
SYNTAX 1.2.826.0.1.3344810.7.14)
The syntax definition is:
(1.2.826.0.1.3344810.7.14 DESC 'Basic Attributes Constraints
Syntax' )
The ASN.1 for BasicAttConstraintsSyntax is defined in 15.5.2.1 of [9],
as are the semantics of its components.
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
BasicAttConstraintsSyntax = "{" [ sp bacm-authority ]
[ sep sp bacm-pathLenConstraint ]
sp "}"
bacm-authority = id-authority msp BOOLEAN
bacm-pathLenConstraint = id-pathLenConstraint msp INTEGER-0-MAX
id-authority = %x61.75.74.68.6F.72.69.74.79 ; "authority"
id-pathLenConstraint = %x70.61.74.68.4C.65.6E.43.6F.6E.73.74.72.61
%x69.6E.74 ; "pathLenConstraint"
The <BOOLEAN> rule is given in [6].
5.6 Delegated Name Constraints Match
Delegated Name Constraints Match is described in section 15.5.2.2.1 of
[9]. The string description of the holderIssuerMatch matching rule is:
( 2.5.13.56 NAME ' delegatedNameConstraintsMatch'
SYNTAX 1.2.826.0.1.3344810.7.15)
The syntax definition is:
(1.2.826.0.1.3344810.7.15 DESC 'Name Constraints Syntax' )
The ASN.1 for NameConstraintsSyntax is defined in 8.4.2.2 of [9], and
the semantics of its components when used for delegated name constraints
are described in 15.5.2.2.
The LDAP string encoding of an assertion value of this syntax is given
in Section 4.2.
5.7 Time Specification Match
Time Specification Match is described in section 15.1.2.1.1 of [9]. The
string description of the timeSpecificationMatch matching rule is:
( 2.5.13.57 NAME ' timeSpecificationMatch '
SYNTAX 1.2.826.0.1.3344810.7.16)
The syntax definition is:
(1.2.826.0.1.3344810.7.16 DESC 'Time Specification' )
The ASN.1 for TimeSpecification is defined in 7.2 of [7], as are the
semantics of its components.
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
TimeSpecification = "{" sp ts-time
[ "," sp ts-notThisTime ]
[ "," sp ts-timeZone ]
sp "}"
ts-time = id-time msp TSTime
ts-notThisTime = id-notThisTime msp BOOLEAN
ts-timeZone = id-timeZone msp TimeZone
id-time = %x74.69.6D.65 ; "time"
id-notThisTime = %x6E.6F.74.54.68.69.73.54.69.6D.65 ; "notThisTime"
id-timeZone = %x74.69.6D.65.5A.6F.6E.65 ; "timeZone"
TSTime = tst-absolute / tst-periodic
tst-absolute = id-absolute ":" AbsoluteTime
tst-periodic = id-periodic ":" Periods
AbsoluteTime = "{" [ sp at-startTime ]
[ sep sp at-endTime ]
sp "}"
at-startTime = id-startTime msp GeneralizedTime
at-endTime = id-endTime msp GeneralizedTime
id-startTime = %x73.74.61.72.74.54.69.6D.65 ; "startTime"
id-endTime = %x65.6E.64.54.69.6D.65 ; "endTime"
Periods = "{" [ sp Period *( "," sp Period ) ] sp "}"
Period = "{" [ sp p-timesOfDay ]
[ sep sp p-days ]
[ sep sp p-weeks ]
[ sep sp p-months ]
[ sep sp p-years ]
sp "}"
p-timesOfDay = id-timesOfDay msp DayTimeBands
p-days = id-days msp Days
p-weeks = id-weeks msp Weeks
p-months = id-months msp Months
p-years = id-years msp Years
id-timesOfDay = %x74.69.6D.65.73.4F.66.44.61.79 ; "timesOfDay"
id-days = %x64.61.79.73 ; "days"
id-weeks = %x77.65.65.6B.73 ; "weeks"
id-months = %x6D.6F.6E.74.68.73 ; "months"
id-years = %x79.65.61.72.73 ; "years"
DayTimeBands = "{" sp DayTimeBand *( "," sp DayTimeBand ) sp "}"
DayTimeBand = "{" [ sp dtb-startDayTime ]
[ sep sp dtb-endDayTime ]
sp "}"
dtb-startDayTime = id-startDayTime msp DayTime
dtb-endDayTime = id-endDayTime msp DayTime
id-startDayTime = %x73.74.61.72.74.44.61.79.54.69.6D.65
; "startDayTime"
id-endDayTime = %x65.6E.64.44.61.79.54.69.6D.65 ; "endDayTime"
DayTime = "{" sp dt-hour
[ "," sp dt-minute ]
[ "," sp dt-second ]
sp "}"
dt-hour = id-hour msp INTEGER ; 0 to 23
dt-minute = id-minute msp INTEGER ; 0 to 59
dt-second = id-second msp INTEGER ; 0 to 59
id-hour = %x68.6F.75.72 ; "hour"
id-minute = %x6D.69.6E.75.74.65 ; "minute"
id-second = %x73.65.63.6F.6E.64 ; "second"
Days = days-intDay / days-bitDay / days-dayOf
days-intDay = id-intDay ":" SET-OF-INTEGER
days-bitDay = id-bitDay ":" BitDay
days-dayOf = id-dayOf ":" XDayOf
id-intDay = %x69.6E.74.44.61.79 ; "intDay"
id-bitDay = %x62.69.74.44.61.79 ; "bitDay"
id-dayOf = %x64.61.79.4F.66 ; "dayOf"
SET-OF-INTEGER = "{" [ sp INTEGER *( "," sp INTEGER ) ] "}"
BitDay = BIT-STRING / day-bit-list
day-bit-list = "{" [ sp day *( "," sp day ) ] sp "}"
day = %x73.75.6E.64.61.79 ; "sunday"
/ %x6D.6F.6E.64.61.79 ; "monday"
/ %x74.75.65.73.64.61.79 ; "tuesday"
/ %x77.65.64.6E.65.73.64.61.79 ; "wednesday"
/ %x74.68.75.72.73.64.61.79 ; "thursday"
/ %x66.72.69.64.61.79 ; "friday"
/ %x73.61.74.75.72.64.61.79 ; "saturday"
XDayOf = xdo-first / xdo-second / xdo-third / xdo-fourth / xdo-fifth
xdo-first = id-first ":" NamedDay
xdo-second = id-second ":" NamedDay
xdo-third = id-third ":" NamedDay
xdo-fourth = id-fourth ":" NamedDay
xdo-fifth = id-fifth ":" NamedDay
NamedDay = nd-intNamedDays / nd-bitNamedDays
nd-intNamedDays = id-intNamedDays ":" day
nd-bitNamedDays = id-bitNamedDays ":" ( BIT-STRING / day-bit-list )
id-intNamedDays = %x69.6E.74.4E.61.6D.65.64.44.61.79.73
; "intNamedDays"
id-bitNamedDays = %x62.69.74.4E.61.6D.65.64.44.61.79.73
; "bitNamedDays"
Weeks = weeks-allWeeks / weeks-intWeek / weeks-bitWeek
weeks-allWeeks = id-allWeeks ":" NULL
weeks-intWeek = id-intWeek ":" SET-OF-INTEGER
weeks-bitWeek = id-bitWeek ":" BitWeek
id-allWeeks = %x61.6C.6C.57.65.65.6B.73 ; "allWeeks"
id-intWeek = %x69.6E.74.57.65.65.6B ; "intWeek"
id-bitWeek = %x62.69.74.57.65.65.6B ; "bitWeek"
BitWeek = BIT-STRING / week-bit-list
week-bit-list = "{" [ sp week-bit *( "," sp week-bit ) ] sp "}"
week-bit = %x77.65.65.6B.31 ; "week1"
/ %x77.65.65.6B.32 ; "week2"
/ %x77.65.65.6B.33 ; "week3"
/ %x77.65.65.6B.34 ; "week4"
/ %x77.65.65.6B.35 ; "week5"
Months = months-allMonths / months-intMonth / months-bitMonth
months-allMonths = id-allMonths ":" NULL
months-intMonth = id-intMonth ":" SET-OF-INTEGER
months-bitMonth = id-bitMonth ":" BitMonth
id-allMonths = %x61.6C.6C.4D.6F.6E.74.68.73 ; "allMonths"
id-intMonth = %x69.6E.74.4D.6F.6E.74.68 ; "intMonth"
id-bitMonth = %x62.69.74.4D.6F.6E.74.68 ; "bitMonth"
BitMonth = BIT-STRING / month-bit-list
month-bit-list = "{" [ sp month-bit *( "," sp month-bit ) ] sp "}"
month-bit = %x6A.61.6E.75.61.72.79 ; "january"
/ %x66.65.62.72.75.61.72.79 ; "february"
/ %x6D.61.72.63.68 ; "march"
/ %x61.70.72.69.6C ; "april"
/ %x6D.61.79 ; "may"
/ %x6A.75.6E.65 ; "june"
/ %x6A.75.6C.79 ; "july"
/ %x61.75.67.75.73.74 ; "august"
/ %x22.73.65.70.74.65.6D.62.65.72 ; "september"
/ %x6F.63.74.6F.62.65.72 ; "october"
/ %x6E.6F.76.65.6D.62.65.72 ; "november"
/ %x64.65.63.65.6D.62.65.72 ; "december"
Years = "{" [ sp Year *( "," sp Year ) ] sp "}"
Year = INTEGER ; must be >= 1000
TimeZone = INTEGER ; -12 to 12
The <NULL> rule is given in [6].
5.8 Acceptable Certificate Policies Match
Acceptable Certificate Policies Match is described in section 15.5.2.3.1
of [9]. The string description of the acceptableCertPoliciesMatch
matching rule is:
( 2.5.13.59 NAME 'acceptableCertPoliciesMatch'
SYNTAX 1.2.826.0.1.3344810.7.17)
The syntax definition is:
(1.2.826.0.1.3344810.7.17 DESC 'Acceptable Certificate Policies Syntax)
The ASN.1 for AcceptableCertPoliciesSyntax is defined in 15.5.2.3 of
[9], as are the semantics of its components.
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
AcceptableCertPoliciesSyntax = "{" sp CertPolicyId
*( "," sp CertPolicyId ) sp "}"
5.9 Attribute Descriptor Match
Attribute Descriptor Match is described in section 15.3.2.2.1 of [9].
The string description of the attDescriptor matching rule is:
( 2.5.13.58 NAME 'attDescriptor'
SYNTAX 1.2.826.0.1.3344810.7.18)
The syntax definition is:
(1.2.826.0.1.3344810.7.18 DESC 'Attribute Descriptor Syntax')
The ASN.1 for AttributeDescriptorSyntax is defined in 15.3.2.2 of [9],
as are the semantics of its components.
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
AttributeDescriptorSyntax = "{" sp ads-identifier
"," sp ads-attributeSyntax
[ "," sp ads-name ]
[ "," sp ads-description ]
"," sp ads-dominationRule
sp "}"
ads-identifier = id-identifier msp AttributeIdentifier
ads-attributeSyntax = id-attributeSyntax msp AttributeSyntax
ads-name = id-name msp AttributeName
ads-description = id-description msp AttributeDescription
ads-dominationRule = id-dominationRule msp PrivilegePolicyIdentifier
id-identifier = %x69.64.65.6E.74.69.66.69.65.72 ; "identifier"
id-attributeSyntax = %x61.74.74.72.69.62.75.74.65.53.79.6E.74.61.78
; "attributeSyntax"
id-name = %x6E.61.6D.65 ; "name"
id-description = %x64.65.73.63.72.69.70.74.69.6F.6E
; "description"
id-dominationRule = %x64.6F.6D.69.6E.61.74.69.6F.6E.52.75.6C.65
; "dominationRule"
AttributeSyntax = OCTET-STRING ; an empty string is not allowed
AttributeIdentifier = AttributeType
AttributeName = UTF8String ; an empty string is not allowed
AttributeDescription = UTF8String ; an empty string is not allowed
PrivilegePolicyIdentifier = "{" sp ppi-privilegePolicy ","
sp ppi-privPolSyntax
sp "}"
ppi-privilegePolicy = id-privilegePolicy msp PrivilegePolicy
ppi-privPolSyntax = id-privPolSyntax msp InfoSyntax
id-privilegePolicy = %x70.72.69.76.69.6C.65.67.65.50.6F.6C.69.63.79
; "privilegePolicy"
id-privPolSyntax = %x70.72.69.76.50.6F.6C.53.79.6E.74.61.78
; "privPolSyntax"
PrivilegePolicy = OBJECT-IDENTIFIER
InfoSyntax = is-content / is-pointer
is-content = id-content ":" DirectoryString
is-pointer = id-pointer ":" InfoSyntaxPointer
id-content = %x63.6F.6E.74.65.6E.74 ; "content"
id-pointer = %x70.6F.69.6E.74.65.72 ; "pointer"
InfoSyntaxPointer = "{" sp isp-name
[ "," sp isp-hash ]
sp "}"
isp-name = id-name msp GeneralNames
isp-hash = id-hash msp HASH
id-hash = %x68.61.73.68 ; "hash"
HASH = "{" sp h-algorithmIdentifier ","
sp h-hashValue
sp "}"
h-algorithmIdentifier = id-algorithmIdentifier msp AlgorithmIdentifier
h-hashValue = id-hashValue msp BIT-STRING
id-algorithmIdentifier = %x61.6C.67.6F.72.69.74.68.6D.49.64.65.6E.74
%x69.66.69.65.72 ; "algorithmIdentifier"
id-hashValue = %x68.61.73.68.56.61.6C.75.65 ; "hashValue"
The <UTF8String> rule is given in [6].
5.10 Source of Authority Match
Note. This rule has not been defined by X.509, but this is perhaps an
omission that should be rectified. It is an easy matching rule to
define since it has a null syntax i.e. we will be matching on whether
the extension is present or not.
Source of Authority Match returns TRUE if an attribute certificate
contains an SOA Identifier extension. The SOA Identifier extension is
described in section 15.3.2.1 of [9]. The string description of the
sOAIdentifierMatch matching rule is:
( 2.5.13.x NAME 'sOAIdentifierMatch'
SYNTAX 1.2.36.79672281.1.5.1)
The syntax definition of 1.2.36.79672281.1.5.1 (NULL) is given in [3].
6 PMI Object Classes
The definitions of the PMI directory object classes can be found in
section 17.1 of [9]. They are repeated here for the convenience of the
reader.
pmiUser OBJECT-CLASS ::= {
-- a privilege holder
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {attributeCertificateAttribute}
ID { joint-iso-ccitt(2) ds(5) objectClass(6) pmiUser (24) } }
pmiAA OBJECT-CLASS ::= {
-- an attribute authority
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {aACertificate |
attributeCertificateRevocationList |
attributeAuthorityRevocationList}
ID { joint-iso-ccitt(2) ds(5) objectClass(6) pmiAA (25) } }
pmiSOA OBJECT-CLASS ::= {
-- a PMI Source of Authority
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {attributeCertificateRevocationList |
attributeAuthorityRevocationList |
attributeDescriptorCertificate}
ID { joint-iso-ccitt(2) ds(5) objectClass(6) pmiSOA (26) } }
attCertCRLDistributionPt OBJECT-CLASS ::= {
-- an AC CRL distribution point
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN { attributeCertificateRevocationList |
attributeAuthorityRevocationList }
ID { joint-iso-ccitt(2) ds(5) objectClass(6)
attCertCRLDistributionPts (27) } }
pmiDelegationPath OBJECT-CLASS ::= {
-- an object that may contain a delegation path
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN { delegationPath }
ID { joint-iso-ccitt(2) ds(5) objectClass(6) delegationPath (33) } }
privilegePolicy OBJECT-CLASS ::= {
-- an object that may contain privilege policy information
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {privPolicy }
ID { joint-iso-ccitt(2) ds(5) objectClass(6) privilegePolicy (32) } }
7. Filter Examples
The following examples are written using the string representation of
Search filters defined in [14]. Line-breaks have been added as an aid to
readability.
i) To exactly match one attribute certificate using equalityMatch with
attributeCertificateExactMatch and
GSERAttributeCertificateExactAssertion
(attributeCertificateAttribute={serialNumber 12345 , issuer {
issuerName { directoryName rdnSequence:"O=truetrust ltd, C=GB" })
ii) To exactly match one attribute certificate using equalityMatch with
attributeCertificateExactMatch and SimpleCertificateExactAssertion
(attributeCertificateAttribute=12345$O=truetrust ltd, C=GB)
iii) To match on the serial number of an attribute certificate using
extensibleMatch with component matching [13]
(attributeCertificateAttribute:componentFilterMatch:=
item:{ component "serialNumber", rule integerMatch,
value 12345 })
iv) To exactly match one attribute certificate using extensibleMatch
with component matching
(attributeCertificateAttribute:componentFilterMatch:=and:{
item:{ component "serialNumber", rule integerMatch, value 12345 }
item:{ component "issuer.issuerName.directoryName.rdnSequence", rule
distinguishedNameMatch, value "O=truetrust ltd, C=GB" } })
v) To match attribute certificates containing a certain role
To Be Worked Out Later#
8. Security Considerations
This [Internet Draft/Standard] describes the schema for the storage
and matching of PMI attributes (attribute certificates, revocation lists
etc.) in an LDAP directory server. It does not address the protocol for
the retrieval of this information.
LDAP servers SHOULD use authentication and access control methods to
protect this information during its storage from unauthorised
modification and retrieval. In addition, clients MAY choose to
encrypt the attributes in the attribute certificates before storing
them in an LDAP server to ensure their confidentiality.
9. References
Normative
[1] Bradner, S. The Internet Standards Process -- Revision 3. RFC
2026 October 1996.
[2] Chadwick, D.W., Legg, S. "Internet X.509 Public Key Infrastructure
LDAP Schema and Syntaxes for PKIs" <draft-pkix-ldap-pki-schema-00.txt>,
June 2002
[3] S. Legg, "Generic String Encoding Rules", <draft-legg-ldap-gser-
XX.txt>, March 2002, a work in progress
[4] J. Sermersheim "Lightweight Directory Access Protocol (v3)" <draft-
ietf-ldapbis-protocol-02.txt> July 2001
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] S. Legg, "Common Elements of GSER Encodings", <draft-legg-ldap-gser-
abnf-XX.txt>, March 2002, a work in progress
[7] ITU-T Rec. X.520(2000) The Directory: Selected Attribute Types
[9] ITU-T Rec. X.509(2000) The Directory: Authentication
Framework
[10] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997
Informative
[13] S. Legg, "LDAP & X.500 Component Matching Rules", <draft-legg-
ldapext-component-matching-04.txt>, November 2001, a work in progress
[14] Howes, T. "The String Representation of LDAP Search Filters". RFC
2254, December 1997.
10. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it has
made any effort to identify any such rights.
Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. [BCP-11]
Copies of claims of rights made available for publication and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard.
Please address the information to the IETF Executive
Director.
11. Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
12. Authors' Addresses
David Chadwick
IS Institute
University of Salford
Salford
England
M5 4WT
Email: d.w.chadwick@salford.ac.uk
Steven Legg
Adacel Technologies Ltd.
405-409 Ferntree Gully Road,
Mount Waverley,
Victoria, 3149
Australia
Email: steven.legg@adacel.com.au
13. Changes
>From Version 00
i) Added ABNF notation for all of the syntaxes.
ii) Removed the restriction on the syntax of Distribution Point Names.
iii) Removed constraints on IssuerSerial.
iv) Bug detected in X.509 AttributeCertificateExactMatch that will need
resolving.
v) Changed the string encodings for non-exact matches to keywords for
each component instead of $ separators.
>From Version 01
i) Added and corrected all X.509 PKI schema definitions, since these
have been removed from RFC2252-bis.
ii) Changed assertion syntaxes to use the syntax defined by Component
Matching Rules
iii) Included all the matching rules for AC extensions
>From Version 02 of <draft-pkix-ldap-schema-02.txt>
i) PKI and PMI schema has been split into separate IDs
ii) Example have been added
iii) Text has been added to mandate that servers must store and
retrieve syntaxes containing digital signatures exactly as given.
iv) Text has been removed concerning the use of the ;binary encoding
option, as per the decision of the LDAPBIS group.
14. Outstanding Issues
i. There is still a bug in the X.509
AttributeCertificateExactAssertion. It reads:
AttributeCertificateExactAssertion ::= SEQUENCE {
serialNumber CertificateSerialNumber OPTIONAL,
issuer IssuerSerial }
OPTIONAL should be removed from the serialNumber. IssuerSerial should be
replaced by AttCertIssuer. This ID has assumed that the change will be
made.
ii. Should the AttributeType in Attribute Certificate Match allow the
LDAP <descr> encoding option for describing attribute type OIDs
(i.e. user friendly names instead of object identifiers)? Note
that attribute names are not guaranteed to be unique, whereas OIDs
are.
iii. The Source of Authority Match is not defined in X.509. Do we
prefer compatibility with X.509 and remove it, or get X.509 to add
it.
15. Table of Contents
1. Introduction 1
2. Subschema Publishing 2
3. PMI Attributes and Syntaxes 2
3.1 Attribute Certificate Attribute 2
3.2 Attribute Authority Certificate Attribute 2
3.3 Attribute Descriptor Certificate Attribute 3
3.4 Attribute Certificate Syntax 3
3.5 Attribute Certificate Revocation List Attribute 3
3.6 Attribute Authority Certificate Revocation List Attribute 4
3.7 Delegation Path Attribute 4
3.8 Delegation Path Syntax 4
4 PMI Matching Rules 5
4.1 Attribute Certificate Exact Match 5
4.2 Attribute Certificate Match 9
5 AC Extensions Matching Rules 10
5.1 Holder Issuer Match 10
5.2 Delegation Path Match 10
5.3 Authority Attribute Identifier Match 11
5.4 Role Specification Certificate Identifier Match 11
5.5 Basic Attribute Constraints Match 12
5.6 Delegated Name Constraints Match 12
5.7 Time Specification Match 13
5.8 Acceptable Certificate Policies Match 16
5.9 Attribute Descriptor Match 16
5.10 Source of Authority Match 17
6 PMI Object Classes 18
7. Filter Examples 19
8. Security Considerations 19
9. References 20
Normative 20
Informative 20
10. Intellectual Property Notice 20
11. Copyright 21
12. Authors' Addresses 21
13. Changes 22
14. Outstanding Issues 22
15. Table of Contents 23
Datatracker
Report a datatracker bug
draft-ietf-pkix-ldap-pmi-schema-00
None
| Document | Document type |
Expired Internet-Draft
(pkix WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Authors |
Dr. David W. Chadwick
,
Steven Legg
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |