INTERNET-DRAFT D. W. Chadwick
PKIX WG University of Salford
Intended Category: Standards Track S. Legg
Adacel Technologies
8 September 2000
Internet X.509 Public Key Infrastructure
Additional LDAP Schema for PKIs and PMIs
<draft-ietf-pkix-ldap-schema-01.txt>
Copyright (C) The Internet Society (2000). 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.
This Internet-Draft expires on 8 March 2001.
ABSTRACT
This document describes LDAP schema features in addition to RFC 2587
that are needed to support a Privilege Management Infrastructure and
a Public Key Infrastructure.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Chadwick & Legg Expires 8 March 2001 [Page 1]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
document are to be interpreted as described in RFC 2119 [5].
1. Introduction
RFC2587 [8] describes some of the subschema applicable to LDAPv2
servers [2], specifically the public key certificate related
attribute types and object classes that MUST or MAY be supported.
This [document/ID/standard] does not revoke any of the contents of
RFC2587, but supplements them.
RFC2587 is equally applicable to LDAPv3 [4] servers as to LDAPv2
servers and MUST be supported by LDAPv3 servers.
Neither RFC2587 nor the user schema for LDAPv3 (RFC2256 [3]) nor the
attribute syntax definitions for LDAPv3 (RFC2252 [7]) describe in
detail the matching rules that should be supported by LDAP servers,
nor do they describe how attribute value assertions for each matching
rule should be encoded in filter items.
Finally none of these documents mention attributeCertificates or any
schema to support privilege management, since these concepts
superseded the publishing of the RFCs.
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 which support extensible matching
SHOULD publish the matching rules they support in the matchingRule
and matchingRuleUse operational attributes.
3. Public Key Certificate Matching Rules
X.509 [9] supports both equality and flexible certificate matching
rules by the server, via the certificateExactMatch and
certificateMatch MATCHING-RULEs respectively. (For example, a client
may flexibly search for certificates with a particular validity time,
key usage, policy or other field.) LDAPv3 servers MUST support the
certificateExactMatch matching rule. Clients MAY support
certificateExactMatch values for equalityMatch filters. LDAPv3
servers SHOULD support the certificateMatch matching rule. If the
server does support flexible matching (either via certificateMatch or
Chadwick & Legg Expires 8 March 2001 [Page 2]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
some other matching rule), then the extensibleMatch filter of the
Search request MUST be supported. Clients MAY support the
extensibleMatch filter and one or more of the optional elements of
certificateMatch.
Neither of the above matching rules are mentioned in the LDAPv3
standards [3 or 7], and only the equality matching rule is mentioned
in [8], but nowhere is it defined for LDAP servers.
3.1 Certificate Exact Match
Certificate exact match is defined in 11.3.1 of [9]. The string
description of the certificateExactMatch matching rule is:
( 2.5.13.34 NAME 'certificateExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.x )
Note. x is still to be allocated
The LDAP syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.x
DESC 'Certificate Serial Number and Issuer' )
The LDAP string encoding of an assertion value of this syntax is
given by the following Augmented BNF [10]:
CertificateExactAssertion = CertificateSerialNumber "$"
; certificate serial number
Name
; certificate issuer
CertificateSerialNumber = 1*DIGIT
DIGIT = "0" / NON-ZERO-DIGIT
NON-ZERO-DIGIT = "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8" / "9"
Name = DQUOTE ldapdn DQUOTE
; rdnSequence
DQUOTE = %x22
; " (double quote)
ldapdn = *SafeUTF8Character
SafeUTF8Character = %x01-21 / %x23-7F /
Chadwick & Legg Expires 8 March 2001 [Page 3]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
; ASCII minus DQUOTE
DQUOTE DQUOTE /
; escaped double quote
%xCO-DF %x80-BF /
; 2 byte UTF8 char
%xEO-EF 2(%x80-BF) /
; 3 byte UTF8 char
%xFO-F7 3(%x80-BF) /
; 4 byte UTF8 char
%xF8-FB 4(%x80-BF) /
; 5 byte UTF8 char
%xFC-FD 5(%x80-BF)
; 6 byte UTF8 char
The <Name> rule encodes the rdnSequence component (a distinguished
name) as an LDAPDN character string between double quotes. The
character string is first derived according to the
<distinguishedName> rule in Section 3 of [6], and then any embedded
double quotes are escaped by repeating the double quotes character.
This resulting string is output between double quotes.
3.2 Certificate Match
Certificate match is defined in 11.3.2 of [9]. The string description
of the certificateMatch matching rule is:
( 2.5.13.35 NAME 'certificateMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.y )
Note. y is still to be allocated
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.y DESC 'Certificate Assertion' )
The ASN.1 for certificateAssertion is defined in 11.3.2 of [9], as
are the semantics of each of its component types.
The LDAP string encoding of an assertion value of this syntax is
given by the following ABNF:
CertificateAssertion = "(" sp
["NUMBER" sp CertificateSerialNumber sp]
; optional certificate serial number
["ISSUER" sp Name sp] ; optional certificate issuer name
["SKEYID" sp SubjectKeyIdentifier sp]
Chadwick & Legg Expires 8 March 2001 [Page 4]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
; optional subject key identifier
["AKEYID" sp AuthorityKeyIdentifier sp]
; optional authority key identifier
["TIME" sp Time sp] ; optional certificate validity time
["PKTIME" sp GeneralizedTime sp] ; optional private key validity time
["ALGOID" sp numericoid sp] ; optional subject public
; key algorithm object identifier
["USE" sp KeyUsage sp] ; optional key usage bits
; The first (left most) bit represents
; key usage digital signature (bit 0).
; Note that if less bits are present
; than defined in the keyUsage field it
; is assumed that those right most bits
; that are not present have the value 0
["ALTNAMETYPE" sp AltNameType sp]
; optional subject alternative name type
["POLICIES" sp CertPolicySet sp] ; optional set of certificate policy
; object identifiers
["TO" sp PathToName sp] ; optional name that must not be
; prohibited from having a
; certification path constructed to it
; via a Name Constraints extension
["SUBJECT" sp Name sp] ; optional subject name
["CONSTRAINTS" sp NameConstraintsSyntax sp]
; optional subject name constraints
")"
sp = " "
SubjectKeyIdentifier = KeyIdentifier
AuthorityKeyIdentifier = KeyIdentifier
; authority key identifier
; For simplicity, authorityCertIssuer and
; authorityCertSerialNumber are omitted.
KeyIdentifier = h2string
h2string = "'" *(2HEXDIG) "'H"
KeyUsage = bstring
bstring = "'" *BIT "'B"
AltNameType = builtinNameForm /
; one of the X.509 built in
; Name Forms being sought
numericoid
Chadwick & Legg Expires 8 March 2001 [Page 5]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
; or the OID of another
; (privately defined) Name Form
builtinNameForm = "rfc822" / ; rfc822Name
"dns" / ; dNSName
"x400" / ; x400Address
"ldapdn" / ; directoryName
"edi" / ; ediPartyName
"uri" / ; uniformResourceIdentifier
"ip" / ; iPAddress
"oid" ; registeredId
CertPolicySet = CertPolicyId *( "+" CertPolicyId )
CertPolicyId = numericoid
PathToName = Name
Time = GeneralizedTime
; generalizedTime
; Note that utcTime is encoded as a
; GeneralizedTime by assuming the year
; ranges from 1950 to 2049
GeneralizedTime = 10DIGIT *2(2DIGIT) fraction
[ "Z" | differential ]
fraction = ( "." / "," ) 1*DIGIT
differential = ( "-" / "+" ) *2(2DIGIT)
NameConstraintsSyntax = [ "permitted" GeneralSubtrees]
; permitted namespaces for a name
[ "excluded" GeneralSubtrees]
; excluded namespaces for a name
GeneralSubtrees = 1*( "+" GeneralSubtree )
GeneralSubtree = GeneralName
; base only at present
; minimum and maximum omitted
; for simplification
Editors' note. The <GeneralSubtree> rule permits only a subset of the
allowed values of name constraints (minimum and maximum are missing).
Do we want to add these?
GeneralName = "rfc822 +" IA5String /
Chadwick & Legg Expires 8 March 2001 [Page 6]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
; rfc822Name
"dns +" IA5String /
; dNSName
"x400 +" ORAddress /
; x400Address
"ldapdn +" Name /
; directoryName
"edi +" EDIPartyName /
; ediPartyName
"uri +" IA5String /
; uniformResourceIdentifier
"ip +" h2string /
; iPAddress
"oid +" numericoid /
; registeredId
numericoid "+" OpenType
; otherName
IA5String = DQUOTE *SafeIA5Character DQUOTE
ORAddress = DQUOTE *SafeIA5Character DQUOTE
SafeIA5Character = %x01-21 / %x23-7F /
; ASCII minus DQUOTE
DQUOTE DQUOTE
; escaped double quote
EDIPartyName = [DirectoryString] "+"
; name Assigner
DirectoryString
; party Name
DirectoryString = DQUOTE *SafeUTF8Character DQUOTE
OpenType = h2string
numericoid = ObjIdComponent *( "." ObjIdComponent )
ObjIdComponent = "0" / ( NON-ZERO-DIGIT *DIGIT )
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
BIT = "0" / "1"
The <KeyIdentifier> rule encodes an OCTET STRING key identifier as a
hexadecimal character string. Each octet is represented by a pair of
hexadecimal characters. The <SubjectKeyIdentifier> rule encodes the
Chadwick & Legg Expires 8 March 2001 [Page 7]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
subject key. The <AuthorityKeyIdentifier> rule encodes the
KeyIdentifier component of the AuthorityKeyIdentifier ASN.1 type.
Editors' note. For simplification, the <AuthorityKeyIdentifier> rule
permits only a subset of the X.509 allowed values for authority key
identifier. Specifically authority issuer name and authority
certificate serial number are missing. Is this the best choice to
make?
The <KeyUsage> rule represents the key usage bit string rendered as a
binary number between quotes. The first (left most) bit represents
key usage digitalSignature (bit 0). Note that if less bits are
present than defined in the keyUsage field it is assumed that those
right most bits that are not present and have the value 0.
The <GeneralizedTime> rule encodes a GeneralizedTime string as a
printable string as specified in [7]. The <Time> rule encodes the
utcTime alternative as a GeneralizedTime by prepending two digits for
the century. The century is assumed to be 19 if the year is between
50 and 99 inclusive. The century is assumed to be 20 if the year is
between 00 and 49 inclusive.
The <ORAddress> rule encodes the x400Address component of a
GeneralName as a character string between double quotes. The
character string is first derived according to Section 4.1 of [11],
and then any embedded double quotes are escaped by repeating the
double quotes character. This resulting string is output between
double quotes.
The <OpenType> rule encodes the value component of otherName as the
hexadecimal character string representing the corresponding BER
encoding.
The <numericoid> rule is equivalent to the definition given in [7]
and encodes the components of the OBJECT IDENTIFIER as digit strings
separated by "." .
Where any optional field is missing this is indicated by the presence
of two contiguous dollar separators (or if the certificate serial
number is missing a certificate assertion that starts with a dollar
separator).
Editors' Notes.
i. We need to decide whether searching for cross certificates should
be supported by this LDAPv3 profile or not. If we decide that this
should be supported, then we will need to define the matching rules
to be supported and the string encodings for the assertion syntaxes
Chadwick & Legg Expires 8 March 2001 [Page 8]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
(in fact this is not too difficult since they are similar to
certificate matching rules and AVAs).
ii. We need to decide if userSMIMECertificates should also be
supported as part of this profile or not.
4. Public Key Certificate Revocation List Matching Rules
X.509[9] defines both equality and flexible matching rules for CRLs,
via the certificateListExactMatch and certificateListMatch MATCHING-
RULEs respectively. LDAPv3 servers MUST support the
certificateListExactMatch matching rule. Clients MAY support
certificateListExactMatch values for equalityMatch filters. LDAPv3
servers MAY support the certificateListMatch matching rule. If the
server does support flexible matching (either via
certificateListMatch or some other matching rule), then the
extensibleMatch filter of the Search request MUST be supported.
Clients MAY support the extensibleMatch filter and one or more of the
optional elements of certificateListMatch.
4.1 Certificate List Exact Match
Certificate List exact match is defined in 11.3.5 of [9]. The string
description of the certificateListExactMatch matching rule is:
( 2.5.13.38 NAME 'certificateListExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.z )
Note. z is still to be allocated
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.z
DESC 'Issuer name, time and distribution point name' )
The LDAP string encoding of an assertion value of this syntax is
given by the following ABNF:
CertificateListExactAssertion = Name "$"
; CRL issuer name
Time "$"
; CRL issuing time(thisUpdate field)
[DistributionPointName]
; the optional distributionPoint
; of the CRL
DistributionPointName = GeneralName /
Chadwick & Legg Expires 8 March 2001 [Page 9]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
"rdn +" RelativeName
RelativeName = DQUOTE *SafeUTF8Character DQUOTE
; a relative distinguished name
The <RelativeName> rule encodes a double quoted string containing a
relative distinguished name as it would appear in an LDAPDN character
string. The character string is first derived according to the
<name-component> rule in Section 3 of [6], and then any embedded
double quotes are escaped by repeating the double quotes character.
This resulting string is output between double quotes.
4.2 Certificate List Match
Certificate List match is defined in 11.3.6 of [9]. The string
description of the certificateListMatch matching rule is:
( 2.5.13.39 NAME 'certificateListMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.w )
Note. w is still to be allocated
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.w DESC 'Certificate List Assertion' )
The ASN.1 for certificateListAssertion is defined in 11.3.6 of [9].
The LDAP string encoding of an assertion value of this syntax is
given by the following ABNF:
CertificateListAssertion = "(" sp
["ISSUER" sp Name sp] ; optional name of RL issuer
["MIN" sp CRLNumber sp] ; optional minimum CRL number
; CRL number must be GE this
["MAX" sp CRLNumber sp] ; optional maximum CRL number
; CRL number must be LE this
["REASONS" sp ReasonFlags sp] ; optional reasons for revocation
["TIME" sp Time sp] ; optional date and time of
; revocation list
["DP" sp DistributionPointName sp] ; the optional distribution point
; of the CRL
["AKEYID" sp AuthorityKeyIdentifier sp]
; optional authority key identifier
")"
Chadwick & Legg Expires 8 March 2001 [Page 10]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
ReasonFlags = bstring
The <ReasonFlags> rule represents the reasonFlags bit string rendered
as a binary number between quotes. The first (left most) bit
represents unused reason flag (bit 0). Note that if less bits are
present than defined in the reason flags field it is assumed that
those right most bits that are not present have the value 0.
5. Privilege Management Schema
ISSUE. Should the PMI schema be put in a separate document, so that
the PKI schema can progress at a faster rate? The reason is that
Matched Values and LDAPv3 Profile reference this ID.
LDAP servers MAY store any type of attribute with the
AttributeCertificate syntax, and LDAP clients MAY request them to be
returned by adding them to the Search Request
AttributeDescriptionList (either explicitly or implicity via
requesting all attributes). LDAP servers that do 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. 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.
For the convenience of the reader, some of the subchema definitions
to support attribute certificates are produced below, but it is
anticipated that these will be moved to a subsequent revision of the
LDAPv3 standard.
5.1 PMI Attributes
The attributeCertificateAttribute holds the privileges of a user.
attributeCertificateAttribute ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4)
Chadwick & Legg Expires 8 March 2001 [Page 11]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
attributeCertificate(58) } }
The aAcertificate holds the privileges of an attribute authority
aACertificate ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4)
aACertificate(61) } }
The attributeDescriptorCertificate is self signed by a source of
authority and holds a description of the privilege and its delegation
rules.
attributeDescriptorCertificate ATTRIBUTE ::= {
WITH SYNTAX AttributeCertificate
EQUALITY MATCHING RULE attributeCertificateExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4)
attributeDescriptorCertificate (62) } }
The attributeCertificateRevocationList holds a list of attribute
certificates that have been revoked.
attributeCertificateRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) } }
The attributeAuthorityList holds a list of AA certificates that have
been revoked.
attributeAuthorityRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) } }
5.2 PMI Object Classes
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) } }
Chadwick & Legg Expires 8 March 2001 [Page 12]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
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) } }
5.3 PMI Matching Rules
5.3.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.
attributeCertificateExactMatch MATCHING-RULE ::= {
SYNTAX AttributeCertificateExactAssertion
ID { joint-iso-ccitt(2) ds(5) mr (13)
attributeCertificateExactMatch (45) } }
AttributeCertificateExactAssertion ::= SEQUENCE {
serialNumber CertificateSerialNumber,
issuer IssuerSerial }
CertificateSerialNumber ::= INTEGER
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serial CertificateSerialNumber,
issuerUID UniqueIdentifier OPTIONAL }
UniqueIdentifier ::= BIT STRING
The LDAP definition for the above matching rule is:
Chadwick & Legg Expires 8 March 2001 [Page 13]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
( 2.5.13.45 NAME 'attributeCertificateExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.m )
Note that the value of m is still to be allocated.
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.m DESC 'Attribute certificate serial
number and public key issuer and serial number' )
The LDAP string encoding of an assertion value of this syntax is
given by the following ABNF:
AttributeCertificateExactAssertion =
CertificateSerialNumber "$"
; serial number of the attribute
; certificate
IssuerSerial
; the identify of the AA
IssuerSerial = GeneralNames "$"
; one or more names of the issuer of
; a public key certificate
CertificateSerialNumber "$"
; the serial number of the public
; key certificate
[ UniqueIdentifier ]
; an optional unique identifier for
; the AA (issuer)
EDITOR's NOTE. There appears to be a bug in the X.509(2001) standard
in that the matching rule syntax and ACv2 syntax are not the same.
Certificate serial number is mandatory in the matching rule but may
not be present in the AC. Resolution of this is awaited, and will
probably cause a change of the matching rule syntax.
UniqueIdentifier = bstring / hstring
hstring = "'" *HEXDIG "'H"
The issuerUID is encoded as either a bit string or a hexadecimal
string. The <hstring> rule SHALL NOT be used if the issuerUID is not
a multiple of four bits.
5.3.2 Attribute Certificate Match
Chadwick & Legg Expires 8 March 2001 [Page 14]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
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 {
subject/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.3.6.1.4.1.1466.115.121.1.n )
Note that the value of n is still be assigned.
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.n
DESC 'Attribute Certificate Assertion' )
The LDAP string encoding of an assertion value of this syntax is
given by the following ABNF:
AttributeCertificateAssertion = "(" sp
["HOLDER" sp holder sp] ; optional identification of the AC holder
["ISSUER" sp GeneralNames sp] ; optionally one or more names of the AA
["TIME" sp GeneralizedTime sp] ; an optional validity time for
; the attribute certificate
["TYPES" sp AttributeType *( "+" AttributeType) sp]
; optionally one or more attribute
; types contained in the AC
")"
; NOTE that at least one of the optional components must be present
holder = IssuerSerial /
Chadwick & Legg Expires 8 March 2001 [Page 15]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
; identification of the AC holder
; via its public key certificate
GeneralNames
; one or more names of the holder
AttributeType = numericoid
Editors' Note. Should the <AttributeType> rule allow the LDAP <descr>
encoding option for describing attribute type OBJECT IDENTIFIERs by
defined names ? Attribute names are not guaranteed to be unique,
whereas OIDs are.
Editors' Note. X.509 defines the following matching rules for
matching on various extensions within an attribute certificate.
Before any of them is defined for LDAP, we need to decide how many of
them are really useful. Comments please.
5.3.3 Holder Issuer Match
5.3.4 Delegation Path Match
5.3.5 Authority Attribute Identifier Match
5.3.6 Role Specification Certificate Identifier Match
5.3.7 Basic Attribute Constraints Match
5.3.8 Delegated Name Constraints Match
5.3.9 Time Specification Match
5.3.10 Acceptable Certificate Policies Match
5.3.11 Attribute Descriptor Match
5.3.12 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 present or not.
6. Security Considerations
This [Internet Draft/Standard] describes the schema for the storage
and matching of attribute certificates and revocation lists in an
LDAP directory server. It does not address the protocol for the
Chadwick & Legg Expires 8 March 2001 [Page 16]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
retrieval of this information.
LDAP servers SHOULD use access control information to protect the
information during its storage. In addition, clients MAY choose to
encrypt the attributes in the attribute certificates before storing
them in an LDAP server.
7. References
[1] Bradner, S. The Internet Standards Process -- Revision 3. RFC
2026 October 1996.
[2] Yeong, W., Howes, T., and Kille, S. "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
[3] M.Wahl. "A Summary of the X.500(96) User Schema for use with
LDAPv3" RFC 2256, Dec 1997
[4] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", Dec. 1997, RFC 2251
[5] S.Bradner. "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[6] M. Wahl, S. Kille, T. Howes. "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished Names",
RFC2253, December 1997.
[7] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, Dec
1997
[8] S.Boeyen, T. Howes, P. Richard "Internet X.509 Public Key
Infrastructure, LDAPv2 Schema", RFC 2587, June 1999
[9] Draft ITU-T Rec. X.509(2001) The Directory: Authentication
Framework
[10] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997
[11] S. Kille, "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998
8. Intellectual Property Notice
Chadwick & Legg Expires 8 March 2001 [Page 17]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
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.
9. Copyright
Copyright (C) The Internet Society (2000). 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.
Chadwick & Legg Expires 8 March 2001 [Page 18]
INTERNET-DRAFT PKIX Operational Protocols - LDAP Schema8 September 2000
10. Authors' Addresses
David Chadwick
IS Institute
University of Salford
Salford
England
M5 4WT
Email: d.w.chadwick@salford.ac.uk
Steven Legg
Adacel Techonologies
250 Bay Street,
Brighton,
Victoria, 3186
Australia
Email: steven.legg@adacel.com.au
11. 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.
Chadwick & Legg Expires 8 March 2001 [Page 19]