INTERNET-DRAFT D. W. Chadwick
PKIX WG University of Salford
Intended Category: Standards Track S. Legg
Adacel Technologies
8 September 2000
16 November 2001
Internet X.509 Public Key Infrastructure
Additional
LDAP Schema and Syntaxes for PKIs and PMIs
<draft-ietf-pkix-ldap-schema-01.txt>
<draft-ietf-pkix-ldap-schema-02.txt>
Copyright (C) The Internet Society (2000). (2001). All Rights Reserved.
Status of this Memo
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. 16 May 2002.
ABSTRACT
This document describes LDAP schema features in addition to RFC 2587 that are needed to support a
X.509 Public Key Infrastructures and Privilege Management Infrastructure
Infrastructures. Specifically, X.509 attribute types, object classes,
matching rules, attribute value syntaxes and
a Public Key Infrastructure. attribute value assertion
syntaxes 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
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 the previously cited documents mention
attributeCertificates or any schema to support privilege management, since these concepts
superseded the publishing of the RFCs. management
infrastructures, so this [document/ID/standard] rectifies this
deficiency.
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 that support extensible matching SHOULD publish the matching
rules they support in the matchingRule and matchingRuleUse operational
attributes.
3. Public Key Certificate and CRL Attributes and Syntaxes
3.1 userCertificate Attribute
The userCertificate attribute type contains the public-key certificates
a user has obtained from one or more CAs. This attribute is to be stored
and requested in the binary form, as 'userCertificate;binary'.
( 2.5.4.36 NAME 'userCertificate'
EQUALITY certificateExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
3.2 cACertificate Attribute
The cACertificate attribute of a CA's directory entry shall be used to
store self-issued certificates (if any) and certificates issued to this
CA by CAs in the same realm as this CA. This attribute is to be stored
and requested in the binary form, as 'cACertificate;binary'.
( 2.5.4.37 NAME 'cACertificate'
EQUALITY certificateExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
3.3 Certificate Syntax
A value in this syntax is the binary string that results from BER/DER-
encoding an X.509 public key certificate. The following string states
the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
Due to the changes from X.509(1988) to X.509(1993) and subsequent
changes to the ASN.1 definition to support certificate extensions, no
string representation is defined, and values in this syntax MUST only be
transferred using the binary encoding, by requesting or returning the
attributes with descriptions "userCertificate;binary" or
"caCertificate;binary". The BNF notation in RFC 1778 [12] for "User
Certificate" is not recommended to be used.
3.4 authorityRevocationList Attribute
A value of this attribute is a list of CA certificates that are no
longer valid. This attribute is to be stored and requested in the
binary form, as 'authorityRevocationList;binary'.
( 2.5.4.38 NAME 'authorityRevocationList'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
3.5 certificateRevocationList Attribute
A value of this attribute is a list of user certificates that are no
longer valid. This attribute is to be stored and requested in the
binary form, as 'certificateRevocationList;binary'.
( 2.5.4.39 NAME 'certificateRevocationList'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
3.6 deltaRevocationList Attribute
This attribute contains a list of revoked certificates (user or CA) that
is an addition to a previous certificate revocation list. This
attribute is to be stored and requested in the binary form, as
'deltaRevocationList;binary'.
( 2.5.4.53 NAME 'deltaRevocationList'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
3.7 Certificate List Syntax
A value in this syntax is the binary string that results from BER/DER-
encoding an X.509 certificate revocation list. The following string
states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
Due to the incompatibility of the X.509(1988) and X.509(1993)
definitions of revocation lists, values in this syntax MUST only be
transferred using a binary encoding, by requesting or returning the
attributes with descriptions "certificateRevocationList;binary",
"authorityRevocationList;binary" or "deltaRevocationList;binary". The
BNF notation in RFC 1778 [12] for "Authority Revocation List" is not
recommended to be used.
3.8 crossCertificatePair Attribute
The following definition is taken from X.509(2000) [9]. The term forward
was used in earlier editions of X.509 for issuedToThisCA and the term
reverse was used in earlier editions for issuedByThisCA.
The issuedToThisCA elements of the crossCertificatePair attribute of a CA's
directory entry shall be used to store all, except self-issued
certificates, issued to this CA. Optionally, the issuedByThisCA elements
of the crossCertificatePair attribute, of a CA's directory entry may contain
a subset of certificates issued by this CA to other CAs. If a CA issues
a certificate to another CA, and the subject CA is not a subordinate to
the issuer CA in a hierarchy, then the issuer CA shall place that
certificate in the issuedByThisCA element of the crossCertificatePair attribute
of its own directory entry. When both the issuedToThisCA and the
issuedByThisCA elements are present in a single attribute value, issuer
name in one certificate shall match the subject name in the other and
vice versa, and the subject public key in one certificate shall be
capable of verifying the digital signature on the other certificate and
vice versa.
This attribute is to be stored and requested in the binary form, as
'crossCertificatePair;binary'.
( 2.5.4.40 NAME 'crossCertificatePair'
EQUALITY certificatePairExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
3.9 Certificate Pair Syntax
A value in this syntax is the binary string that results from BER/DER-
encoding an X.509 public key certificate pair. The following string
states the OID assigned to this syntax:
( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
Values in this syntax MUST only be transferred using a binary encoding,
e.g. by requesting or returning the attribute description
"crossCertificatePair;binary". The BNF notation in RFC 1778 [12] for
"Certificate Pair" is not recommended to be used.
4. Public Key Certificate Matching Rules and Assertion Syntaxes
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 LDAP 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 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 RFC2587 nor the above matching rules are mentioned in user schema for LDAPv3 (RFC2256-bis [3]) nor the
attribute syntax definitions for LDAPv3
standards [3 or 7], and only (RFC2252-bis [7]) describe the equality
certificate matching rules that should be supported by LDAP servers, nor
do they describe how attribute value assertions for each certificate
matching rule is mentioned should be encoded in [8], but nowhere is it filter items. The native LDAP (i.e.
string) encodings for the assertion syntaxes defined in this document
are specified by the Generic String Encoding Rules in Section 8 of [13].
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 [13]. 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 native
LDAP servers.
3.1 encoding for any extension to a syntax's underlying ASN.1 type can
be determined from [13]. In the event that there is a discrepancy
between the ABNF in this document and the encoding determined by [13],
[13] is to be taken as definitive.
4.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 1.2.826.0.1.3344810.7.1)
The LDAP syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.x
(1.2.826.0.1.3344810.7.1
DESC 'Certificate Serial 'CertificateExactAssertion (Serial Number and Issuer' Issuer Name)' )
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 "{" sp cea-serialNumber ","
sp cea-issuer
sp "}"
cea-serialNumber = "0" / NON-ZERO-DIGIT
NON-ZERO-DIGIT id-serialNumber msp CertificateSerialNumber
cea-issuer = "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8" / "9" id-issuer msp Name
id-serialNumber = DQUOTE ldapdn DQUOTE %x73.65.72.69.61.6C.4E.75.6D.62.65.72
; rdnSequence
DQUOTE "serialNumber"
id-issuer = %x22 %x69.73.73.75.65.72 ; " (double quote)
ldapdn "issuer"
Name = *SafeUTF8Character
SafeUTF8Character id-rdnSequence ":" RDNSequence
id-rdnSequence = %x01-21 / %x23-7F /
; ASCII minus DQUOTE
DQUOTE DQUOTE / %x72.64.6E.53.65.71.75.65.6E.63.65 ; 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 "rdnSequence"
CertificateSerialNumber = INTEGER
Note. [14] states that CAs MUST force the rdnSequence component (a distinguished
name) as an LDAPDN character string between double quotes. The
character string is first derived according serialNumber to the
<distinguishedName> rule in Section 3 of [6], be a non-
negative integer. Non-conforming CAs MAY issue certificates with serial
numbers that are negative, or zero. Certificate users SHOULD be
prepared to handle such certificates.
The <sp>, <msp>, <RDNSequence> and then any embedded
double quotes <INTEGER> rules are escaped by repeating the double quotes character.
This resulting string is output between double quotes.
3.2 given in [16].
4.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 1.2.826.0.1.3344810.7.2)
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.y
(1.2.826.0.1.3344810.7.2 DESC 'Certificate Assertion' )
The ASN.1 for certificateAssertion 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" ca-serialNumber ]
[ sep sp Name sp] ; optional certificate issuer name
["SKEYID" ca-issuer ]
[ sep sp SubjectKeyIdentifier sp]
; optional subject key identifier
["AKEYID" ca-subjectKeyIdentifier ]
[ sep sp AuthorityKeyIdentifier sp]
; optional authority key identifier
["TIME" ca-authorityKeyIdentifier ]
[ sep sp Time sp] ; optional certificate validity time
["PKTIME" ca-certificateValid ]
[ sep sp GeneralizedTime sp] ; optional private key validity time
["ALGOID" ca-privateKeyValid ]
[ sep sp numericoid sp] ; optional subject public
; key algorithm object identifier
["USE" ca-subjectPublicKeyAlgID ]
[ sep 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" ca-keyUsage ]
[ sep sp AltNameType sp]
; optional subject alternative name type
["POLICIES" ca-subjectAltName ]
[ sep sp CertPolicySet sp] ; optional set of certificate policy
; object identifiers
["TO" ca-policy ]
[ sep sp PathToName sp] ; optional name that must not be
; prohibited from having a
; certification path constructed to it
; via a Name Constraints extension
["SUBJECT" ca-pathToName ]
[ sep sp Name sp] ; optional subject name
["CONSTRAINTS" ca-subject ]
[ sep sp NameConstraintsSyntax sp]
; optional subject name constraints
")" ca-nameConstraints ]
sp "}"
The <sep> rule is given in [16].
ca-serialNumber = " " id-serialNumber msp
CertificateSerialNumber
ca-issuer = id-issuer msp Name
ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp
SubjectKeyIdentifier
ca-authorityKeyIdentifier = KeyIdentifier id-authorityKeyIdentifier msp
AuthorityKeyIdentifier
ca-certificateValid = KeyIdentifier
; authority key identifier
; For simplicity, authorityCertIssuer and
; authorityCertSerialNumber are omitted.
KeyIdentifier certificateValid msp Time
ca-privateKeyValid = h2string
h2string id-privateKeyValid msp GeneralizedTime
ca-subjectPublicKeyAlgID = "'" *(2HEXDIG) "'H"
KeyUsage id-subjectPublicKeyAlgID msp
OBJECT-IDENTIFIER
ca-keyUsage = bstring
bstring id-keyUsage msp KeyUsage
ca-subjectAltName = "'" *BIT "'B" id-subjectAltName msp AltNameType
ca-policy = builtinNameForm /
; one of the X.509 built in
; id-policy msp CertPolicySet
ca-pathToName = id-pathToName msp Name Forms being sought
numericoid
; or the OID of another
; (privately defined)
ca-subject = id-subject msp Name Form
builtinNameForm
ca-nameConstraints = "rfc822" / ; rfc822Name
"dns" / ; dNSName
"x400" / ; x400Address
"ldapdn" / ; directoryName
"edi" / ; ediPartyName
"uri" / id-nameConstraints msp
NameConstraintsSyntax
id-subjectKeyIdentifier = %x73.75.62.6A.65.63.74.4B.65.79.49.64.65
%x6E.74.69.66.69.65.72
; uniformResourceIdentifier
"ip" / "subjectKeyIdentifier"
id-authorityKeyIdentifier = %x61.75.74.68.6F.72.69.74.79.4B.65.79.49
%x64.65.6E.74.69.66.69.65.72
; iPAddress
"oid" "authorityKeyIdentifier"
id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61
%x6C.69.64 ; registeredId
CertPolicySet "certificateValid"
id-privateKeyValid = CertPolicyId *( "+" CertPolicyId )
CertPolicyId %x70.72.69.76.61.74.65.4B.65.79.56.61.6C
%x69.64 ; "privateKeyValid"
id-subjectPublicKeyAlgID = numericoid
PathToName %x73.75.62.6A.65.63.74.50.75.62.6C.69.63
%x4B.65.79.41.6C.67.49.44
; "subjectPublicKeyAlgID"
id-keyUsage = Name
Time %x6B.65.79.55.73.61.67.65 ; "keyUsage"
id-subjectAltName = GeneralizedTime %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D
%x65 ; generalizedTime "subjectAltName"
id-policy = %x70.6F.6C.69.63.79 ; Note that utcTime is encoded as a "policy"
id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65
; GeneralizedTime by assuming the year "pathToName"
id-subject = %x73.75.62.6A.65.63.74 ; ranges from 1950 to 2049
GeneralizedTime "subject"
id-nameConstraints = 10DIGIT *2(2DIGIT) fraction
[ "Z" | differential ]
fraction %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E
%x74.73 ; "nameConstraints"
SubjectKeyIdentifier = ( "." / "," ) 1*DIGIT
differential KeyIdentifier
KeyIdentifier = ( "-" / "+" ) *2(2DIGIT)
NameConstraintsSyntax OCTET-STRING
AuthorityKeyIdentifier = "{" [ "permitted" GeneralSubtrees]
; permitted namespaces for a name sp aki-keyIdentifier ]
[ "excluded" GeneralSubtrees]
; excluded namespaces for a name
GeneralSubtrees sep sp aki-authorityCertIssuer ]
[ sep sp aki-authorityCertSerialNumber ]
sp "}"
aki-keyIdentifier = 1*( "+" GeneralSubtree )
GeneralSubtree id-keyIdentifier msp KeyIdentifier
aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames
GeneralNames = "{" sp 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? *( "," sp GeneralName ) sp "}"
GeneralName = "rfc822 +" IA5String gn-otherName
/
; rfc822Name
"dns +" IA5String gn-rfc822Name
/
; dNSName
"x400 +" ORAddress gn-dNSName
/
; x400Address
"ldapdn +" Name gn-x400Address
/
; directoryName
"edi +" EDIPartyName gn-directoryName
/
; ediPartyName
"uri +" IA5String gn-ediPartyName
/
; uniformResourceIdentifier
"ip +" h2string gn-uniformResourceIdentifier
/
; iPAddress
"oid +" numericoid 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 ; registeredId
numericoid "+" OpenType "otherName"
gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
; otherName
IA5String "registeredID"
OtherName = DQUOTE *SafeIA5Character DQUOTE "{" 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 Section 8 of [13].
ORAddress = DQUOTE dquote *SafeIA5Character DQUOTE dquote
SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus DQUOTE
DQUOTE DQUOTE dquote
dquote dquote ; escaped double quote
EDIPartyName
dquote = [DirectoryString] "+"
; name Assigner
DirectoryString %x22 ; 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
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. " (double quote)
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. being repeated. This resulting string is
output between double quotes.
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"
aki-authorityCertSerialNumber = id-authorityCertSerialNumber msp
CertificateSerialNumber
id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72
; "keyIdentifier"
id-authorityCertIssuer = %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49
%x73.73.75.65.72 ; "authorityCertIssuer"
id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43.65.72
%x74.53.65.72.69.61.6C.4E.75.6D.62
%x65.72
; "authorityCertSerialNumber"
Time = time-utcTime / time-generalizedTime
time-utcTime = id-utcTime ":" UTCTime
time-generalizedTime = id-generalizedTime ":" GeneralizedTime
id-utcTime = %x75.74.63.54.69.6D.65 ; "utcTime"
id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65
; "generalizedTime"
KeyUsage = BIT-STRING / key-usage-bit-list
key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}"
The <OpenType> <key-usage-bit-list> rule encodes the one bits in a KeyUsage value component of otherName
as the
hexadecimal character string representing the corresponding BER
encoding. a comma separated list of identifiers. The <numericoid> <BIT-STRING> rule is equivalent to the definition given
in [7] [16].
key-usage = id-digitalSignature
/ id-nonRepudiation
/ id-keyEncipherment
/ id-dataEncipherment
/ id-keyAgreement
/ id-keyCertSign
/ id-cRLSign
/ id-encipherOnly
/ id-decipherOnly
id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74.75.72
%x65 ; "digitalSignature"
id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E
; "nonRepudiation"
id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74
; "keyEncipherment"
id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E
%x74 ; "dataEncipherment"
id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74
; "keyAgreement"
id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E
; "keyCertSign"
id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign"
id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79
; "encipherOnly"
id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79
; "decipherOnly"
AltNameType = ant-builtinNameForm / ant-otherNameForm
ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm
ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER
id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D
; "builtinNameForm"
id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D
; "otherNameForm"
BuiltinNameForm = id-rfc822Name
/ id-dNSName
/ id-x400Address
/ id-directoryName
/ id-ediPartyName
/ id-uniformResourceIdentifier
/ id-iPAddress
/ id-registeredId
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"
CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}"
CertPolicyId = OBJECT-IDENTIFIER
NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ]
[ sep sp ncs-excludedSubtrees ]
sp "}"
ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees
ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees
id-permittedSubtrees = %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72
%x65.65.73 ; "permittedSubtrees"
id-excludedSubtrees = %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65
%x65.73 ; "excludedSubtrees"
GeneralSubtrees = "{" sp GeneralSubtree
*( "," sp GeneralSubtree ) sp "}"
GeneralSubtree = "{" sp gs-base
[ "," sp gs-minimum ]
[ "," sp gs-maximum ]
sp "}"
gs-base = id-base msp GeneralName
gs-minimum = id-minimum msp BaseDistance
gs-maximum = id-maximum msp BaseDistance
id-base = %x62.61.73.65 ; "base"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
BaseDistance = INTEGER-0-MAX
The <OBJECT-IDENTIFIER>, <OCTET-STRING>, <IA5String>, <DirectoryString>,
<RelativeDistinguishedName>, <UTCTime>, <GeneralizedTime> and encodes the components <INTEGER-
0-MAX> rules are given in [16].
4.3 Certificate Pair Exact Match
Certificate pair exact match is defined in 11.3.3 of [9]. The string
description of the OBJECT IDENTIFIER as digit strings
separated by "." .
Where any optional field certificatePairExactMatch matching rule is:
( 2.5.13.36 NAME 'certificatePairExactMatch'
SYNTAX 1.2.826.0.1.3344810.7.8)
The LDAP syntax definition is:
(1.2.826.0.1.3344810.7.8
DESC 'Certificate Pair Exact Assertion' )
The ASN.1 for CertificatePairExactAssertion is missing defined in 11.3.3 of [9],
as are the semantics of each of its component types.
The LDAP string encoding of an assertion value of this syntax is indicated given
by the presence following Augmented BNF [10]:
CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ]
[sep sp cpea-issuedBy ]
sp "}"
At least one 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 <cpea-issuedTo> or not. If we decide that this
should <cpea-issuedBy> MUST be supported, then we will need to define present.
cpea-issuedTo = id-issuedToThisCAAssertion msp
CertificateExactAssertion
cpea-issuedBy = id-issuedByThisCAAssertion msp
CertificateExactAssertion
id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73.43
%x41.41.73.73.65.72.74.69.6F.6E
; "issuedToThisCAAssertion"
id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73.43
%x41.41.73.73.65.72.74.69.6F.6E
; "issuedByThisCAAssertion"
4.4 Certificate Pair Match
Certificate pair match is defined in 11.3.4 of [9]. The string
description of the certificatePairMatch matching rules
to be supported and the string encodings rule is:
( 2.5.13.37 NAME 'certificatePairExactMatch'
SYNTAX 1.2.826.0.1.3344810.7.9)
The LDAP syntax definition is:
(1.2.826.0.1.3344810.7.9
DESC 'Certificate Pair Assertion' )
The ASN.1 for CertificatePairAssertion is defined in 11.3.4 of [9], as
are the semantics of each of its component types.
The LDAP string encoding of an assertion syntaxes
(in fact value of this syntax is not too difficult since they are similar to
certificate matching rules given
by the following Augmented BNF [10]:
CertificatePairAssertion = "{" [ sp cpa-issuedTo ]
[sep sp cpa-issuedBy ]
sp "}"
At least one of <cpa-issuedTo> and AVAs).
ii. We need to decide if userSMIMECertificates should also <cpa-issuedBy> MUST be
supported as part of this profile or not.
4. Public Key present.
cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion
cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion
5 Certificate Revocation List Matching Rules
X.509[9] defines both equality and flexible matching rules for CRLs, via
the certificateListExactMatch and certificateListMatch MATCHING-
RULEs MATCHING-RULEs
respectively. LDAPv3 LDAP 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
5.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 1.2.826.0.1.3344810.7.3)
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.z
(1.2.826.0.1.3344810.7.3 DESC 'Issuer 'Certificate List Exact Assertion (Issuer
name, time and distribution point name' name)' )
The ASN.1 for CertificateListExactAssertion is defined in 11.3.5 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:
CertificateListExactAssertion = "{" sp clea-issuer
"," sp clea-thisUpdate
[ "," sp clea-distributionPoint ]
sp "}"
clea-issuer = id-issuer msp Name "$"
; CRL issuer name
clea-thisUpdate = id-thisUpdate msp Time "$"
; CRL issuing time(thisUpdate field)
[DistributionPointName]
clea-distributionPoint = id-distributionPoint msp
DistributionPointName
id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65
; the optional distributionPoint "thisUpdate"
id-distributionPoint = %x64.69.73.74.72.69.62.75.74.69.6F.6E
%x50.6F.69.6E.74 ; of the CRL "distributionPoint"
DistributionPointName = GeneralName dpn-fullName /
"rdn +" RelativeName
RelativeName = DQUOTE *SafeUTF8Character DQUOTE dpn-nameRelativeToCRLIssuer
dpn-fullName = id-fullName ":" GeneralNames
dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":"
RelativeDistinguishedName
id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 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 "fullName"
id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65
%x54.6F.43.52.4C.49.73.73.75.65.72
; "nameRelativeToCRLIssuer"
5.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 1.2.826.0.1.3344810.7.4)
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.w
(1.2.826.0.1.3344810.7.4 DESC 'Certificate List Assertion' )
The ASN.1 for certificateListAssertion CertificateListAssertion is defined in 11.3.6 of [9]. [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:
CertificateListAssertion = "(" "{" [ sp
["ISSUER" cla-issuer ]
[ sep sp Name sp] ; optional name of RL issuer
["MIN" cla-minCRLNumber ]
[ sep sp cla-maxCRLNumber ]
[ sep sp cla-reasonFlags ]
[ sep sp cla-dateAndTime ]
[ sep sp cla-distributionPoint ]
[ sep sp cla-authorityKeyIdentifier ]
sp "}"
cla-issuer = id-issuer msp Name
cla-minCRLNumber = id-minCRLNumber msp CRLNumber sp]
cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber
cla-reasonFlags = id-reasonFlags msp ReasonFlags
cla-dateAndTime = id-dateAndTime msp Time
cla-distributionPoint = id-distributionPoint msp
DistributionPointName
cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp
AuthorityKeyIdentifier
id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72
; optional minimum CRL number "minCRLNumber"
id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72
; CRL number must be GE this
["MAX" sp CRLNumber sp] "maxCRLNumber"
id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; optional maximum CRL number "reasonFlags"
id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; CRL number must be LE this
["REASONS" sp "dateAndTime"
CRLNumber = INTEGER-0-MAX
ReasonFlags sp] ; optional reasons for revocation
["TIME" = BIT-STRING
/ "{" [ sp Time sp] reason-flag
*( "," sp reason-flag ) ] sp "}"
reason-flag = id-unused
/ id-keyCompromise
/ id-cACompromise
/ id-affiliationChanged
/ id-superseded
/ id-cessationOfOperation
/ id-certificateHold
/ id-privilegeWithdrawn
/ id-aACompromise
id-unused = %x75.6E.75.73.65.64 ; optional date and time of "unused"
id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65
; revocation list
["DP" sp DistributionPointName sp] "keyCompromise"
id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65
; the optional distribution point "cACompromise"
id-affiliationChanged = %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68
%x61.6E.67.65.64 ; of the CRL
["AKEYID" sp AuthorityKeyIdentifier sp] "affiliationChanged"
id-superseded = %x73.75.70.65.72.73.65.64.65.64
; optional authority key identifier
")"
ReasonFlags "superseded"
id-cessationOfOperation = 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. %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70
%x65.72.61.74.69.6F.6E
; "cessationOfOperation"
id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F
%x6C.64 ; "certificateHold"
id-privilegeWithdrawn = %x70.72.69.76.69.6C.65.67.65.57.69.74.68
%x64.72.61.77.6E ; "privilegeWithdrawn"
id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65
; "aACompromise"
6. 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 Attribute Certificate and LDAPv3 Profile reference this ID. CRL Attributes
and Syntaxes
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
6.1 Attribute Certificate Attribute
The attributeCertificateAttribute is defined for the
certificate extensions. LDAPv3 servers SHOULD publish the matching
rules that they do support in the matchingRule and matchingRuleUse
operational attributes 17.2.1 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 [9]. It is
anticipated that these will be moved
used to a subsequent revision of hold the
LDAPv3 standard.
5.1 PMI Attributes
The attributeCertificateAttribute holds the privileges attribute certificates of a user.
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 )
6.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
authority.
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 )
6.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.
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 )
6.4 Attribute Certificate Syntax
A value in this syntax is the binary 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' )
6.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.
attributeCertificateRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4) aCRL(59) } }
The attributeAuthorityList corresponding LDAP description is
( 2.5.4.59 NAME 'attributeCertificateRevocationList'
EQUALITY certificateListExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
6.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.
attributeAuthorityRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
EQUALITY MATCHING RULE certificateListExactMatch
ID { joint-iso-ccitt(2) ds(5) attributeType(4) aARL(63) } }
5.2
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 )
7 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) } }
pmiAA OBJECT-CLASS ::= {
-- an Matching Rules
LDAP servers that support the storage of attributes with the
AttributeCertificate syntax MUST support searching for entries
containing specific attribute authority
SUBCLASS OF {top}
KIND auxiliary certificates, via the
attributeCertificateExactMatch matching rule.
LDAPv3Servers MAY CONTAIN {aACertificate |
attributeCertificateRevocationList |
attributeAuthorityRevocationList}
ID { joint-iso-ccitt(2) ds(5) objectClass(6) pmiAA (25) } }
pmiSOA OBJECT-CLASS ::= {
-- a PMI Source support flexible matching for any attributes with the
AttributeCertificate syntax via the attributeCertificateMatch matching
rule or any of Authority
SUBCLASS OF {top}
KIND auxiliary 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 CONTAIN {attributeCertificateRevocationList |
attributeAuthorityRevocationList |
attributeDescriptorCertificate}
ID { joint-iso-ccitt(2) ds(5) objectClass(6) pmiSOA (26) } }
5.3 PMI Matching Rules
5.3.1 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.
7.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. reader (but see Outstanding Issue iv).
attributeCertificateExactMatch MATCHING-RULE ::= {
SYNTAX AttributeCertificateExactAssertion
ID { joint-iso-ccitt(2) ds(5) mr (13)
attributeCertificateExactMatch (45) } }
AttributeCertificateExactAssertion ::= SEQUENCE {
serialNumber CertificateSerialNumber,
issuer IssuerSerial 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.3.6.1.4.1.1466.115.121.1.m )
Note that the value of m is still to be allocated. 1.2.826.0.1.3344810.7.6)
The syntax definition is:
( 1.3.6.1.4.1.1466.115.121.1.m
(1.2.826.0.1.3344810.7.6 DESC 'Attribute certificate exact assertion (
serial number and public key issuer and serial number' details)' )
The LDAP string encoding of an assertion value of this syntax is given
by the following ABNF:
AttributeCertificateExactAssertion = "{" sp acea-serialNumber ","
sp acea-issuer
sp "}"
acea-serialNumber = id-serialNumber msp CertificateSerialNumber "$"
; serial number
acea-issuer = id-issuer msp AttCertIssuer
AttCertIssuer = "{" [ sp aci-issuerName ]
[ sep sp aci-baseCertificateID ]
[ sep sp aci-objectDigestInfo ]
sp "}"
At least one of the attribute
; certificate <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
; the identify of the AA
IssuerSerial "issuerName"
id-objectDigestInfo = GeneralNames "$" %x6F.62.6A.65.63.74.44.69.67.65.73.74.49.6E
%x66.6F ; one or more names of the issuer of "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 ; a public key certificate
CertificateSerialNumber "$" "digestedObjectType"
id-otherObjectTypeID = %x6F.74.68.65.72.4F.62.6A.65.63.74.54.79.70
%x65.49.44 ; the serial number of the public "otherObjectTypeID"
id-digestAlgorithm = %x64.69.67.65.73.74.41.6C.67.6F.72.69.74.68
%x6D ; key certificate "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
[ UniqueIdentifier "," 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 ; an optional unique identifier for "algorithm"
id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 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. "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 = bstring / hstring
hstring %x73.65.72.69.61.6C ; "serial"
id-issuerUID = "'" *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 %x69.73.73.75.65.72.55.49.44 ; "issuerUID"
UniqueIdentifier = BIT-STRING
7.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 {
subject/holder
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 1.2.826.0.1.3344810.7.7 )
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
(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
["HOLDER" aca-holder ]
[ sep sp holder sp] ; optional identification of the AC holder
["ISSUER" aca-issuer ]
[ sep sp GeneralNames sp] ; optionally one or more names of the AA
["TIME" 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 sp]
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 ; an optional validity time for "baseCertificateID"
id-holderName = %x68.6F.6C.64.65.72.4E.61.6D.65
; the attribute certificate
["TYPES" "holderName"
SETOFAttributeType = "{" 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 /
; identification of the AC holder
; via its public key certificate
GeneralNames
; one or more names of the holder "," sp AttributeType = numericoid
Editors' Note. Should the ) sp "}"
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. is given in [16].
8 AC Extensions Matching Rules
X.509 defines the following matching rules for matching on various
extensions within an attribute certificate.
Before any
8.1 Holder Issuer Match
Holder Issuer Match is described in section 17.3.3 of them [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 for LDAP, we need to decide how many in 17.3.3 of
them [9], as are really useful. Comments please.
5.3.3
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 Issuer
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"
8.2 Delegation Path Match
5.3.4
Delegation Path Match
5.3.5 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"
8.3 Authority Attribute Identifier Match
Authority Attribute Identifier Match
5.3.6 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
8.4 Role Specification Certificate Identifier Match
5.3.7
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"
8.5 Basic Attribute Constraints Match
Basic Attribute Constraints Match
5.3.8 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 [16].
8.6 Delegated Name Constraints Match
Delegated Name Constraints Match
5.3.9 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.
8.7 Time Specification Match
Time Specification Match
5.3.10 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 [15], 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 [16].
8.8 Acceptable Certificate Policies Match
Acceptable Certificate Policies Match
5.3.11 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 "}"
8.9 Attribute Descriptor Match
Attribute Descriptor Match
5.3.12 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 [16].
8.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.
6.
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 [13].
9 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) } }
10. 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
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.
11. 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. K. Dally. "A Summary of the X.500(96) X.500(3rd edition) User Schema for use
with
LDAPv3" RFC 2256, Dec 1997 LDAPv3", <draft-ietf-ldapbis-user-schema-00>
[4] M. Wahl, T. Howes, S. Kille, J. Sermersheim "Lightweight Directory Access Protocol (v3)", Dec. 1997, RFC 2251 (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] 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, K. Dally "Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, Dec
1997 <draft-ietf-ldapbis-syntaxes-00>, June 2001
[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) X.509(2000) 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.
[12] Howes, T., Kille, S., Yeong, W., Robbins, C., "The String
Representation of Standard Attribute Syntaxes", RFC 1778, March 1995
[13] S. Legg, "LDAP & X.500 Component Matching Rules", <draft-legg-
ldapext-component-matching-04.txt>, November 2001, a work in progress
[14] R. Housley, W. Ford, W Polk, D. Solo. "Internet X.509 Public Key
Infrastructure - Certificate and CRL Profile" <draft-ietf-pkix-new-
part1-08.txt>, July 2001
[15] ITU-T Rec. X.520(2000) The Directory: Selected Attribute Types
[16] S. Legg, "Common Elements of GSER Encodings", <draft-legg-ldap-
gser-abnf-00.txt>, November 2001, a work in progress
12. 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.
9.
13. Copyright
Copyright (C) The Internet Society (2000). (2001). 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.
10.
14. 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, Technologies Ltd.
405-409 Ferntree Gully Road,
Mount Waverley,
Victoria, 3186 3149
Australia
Email: steven.legg@adacel.com.au
11.
15. Changes from
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
16. Outstanding Issues
i. We need to decide if userSMIMECertificates should also be
supported as part of this profile or not.
ii. Should we obsolete RFC 2587 and copy relevant schema into this
document, or continue to reference it.
iii. Should the PMI schema be put in a separate document, so that the
PKI schema can progress at a faster rate? One reason for
separating them is that Matched Values and LDAPv3 Profile
reference this ID.
iv. 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.
v. 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.
17. Table of Contents
1. Introduction 1
2. Subschema Publishing 2
3. Public Key Certificate and CRL Attributes and Syntaxes 2
3.1 userCertificate Attribute 2
3.2 cACertificate Attribute 2
3.3 Certificate Syntax 2
3.4 authorityRevocationList Attribute 3
3.5 certificateRevocationList Attribute 3
3.6 deltaRevocationList Attribute 3
3.7 Certificate List Syntax 3
3.8 crossCertificatePair Attribute 4
3.9 Certificate Pair Syntax 4
4. Public Key Certificate Matching Rules and Assertion Syntaxes 4
4.1 Certificate Exact Match 5
4.2 Certificate Match 6
4.3 Certificate Pair Exact Match 10
4.4 Certificate Pair Match 11
5 Certificate Revocation List Matching Rules 11
5.1 Certificate List Exact Match 11
5.2 Certificate List Match 12
6. Privilege Management Attribute Certificate and CRL Attributes and
Syntaxes 14
6.1 Attribute Certificate Attribute 14
6.2 Attribute Authority Certificate Attribute 14
6.3 Attribute Descriptor Certificate Attribute 14
6.4 Attribute Certificate Syntax 15
6.5 Attribute Certificate Revocation List Attribute 15
6.6 Attribute Authority Certificate Revocation List Attribute 15
7 PMI Matching Rules 15
7.1 Attribute Certificate Exact Match 16
7.2 Attribute Certificate Match 18
8 AC Extensions Matching Rules 19
8.1 Holder Issuer Match 19
8.2 Delegation Path Match 20
8.3 Authority Attribute Identifier Match 20
8.4 Role Specification Certificate Identifier Match 21
8.5 Basic Attribute Constraints Match 21
8.6 Delegated Name Constraints Match 22
8.7 Time Specification Match 22
8.8 Acceptable Certificate Policies Match 25
8.9 Attribute Descriptor Match 25
8.10 Source of Authority Match 27
9 PMI Object Classes 27
10. Security Considerations 28
11. References 28
12. Intellectual Property Notice 29
13. Copyright 29
14. Authors' Addresses 30
15. Changes 30
16. Outstanding Issues 31