--- /dev/null
+<?xml version="1.0"?>
+<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
+ <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
+ <!ENTITY rfc4120 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
+ <!ENTITY rfc4511 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4511.xml'>
+ <!ENTITY rfc4513 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4513.xml'>
+ <!ENTITY rfc4516 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4516.xml'>
+ <!ENTITY rfc4517 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4517.xml'>
+ <!ENTITY rfc4520 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4520.xml'>
+ <!ENTITY rfc2831 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2831.xml'>
+ <!ENTITY rfc3062 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3062.xml'>
+ <!ENTITY rfc3112 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3112.xml'>
+ <!ENTITY rfc3383 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3383.xml'>
+ <!ENTITY rfc3672 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3672.xml'>
+ <!ENTITY ldapi PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-chu-ldap-ldapi-00.xml'>
+ <!ENTITY ppolicy PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.behera-ldap-password-policy.xml'>
+ <!ENTITY kdcmodel PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-krb-wg-kdc-model-05.xml'>
+]>
+<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
+<?rfc symrefs="yes" ?>
+<rfc
+ ipr="trust200902"
+ category="info"
+ docName="draft-chu-ldap-kdc-schema-00">
+ <front>
+ <title abbrev="LDAP KDC Schema">
+ An LDAP Schema for Kerberos KDC Information
+ </title>
+ <author initials="H." fullname="Howard Chu" surname="Chu">
+ <organization>Symas Corp.</organization>
+ <address>
+ <postal>
+ <street>18740 Oxnard Street, Suite 313A</street>
+ <city>Tarzana</city>
+ <region>California</region>
+ <code>91356</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 818 757-7087</phone>
+ <email>hyc@symas.com</email>
+ <uri>http://www.symas.com</uri>
+ </address>
+ </author>
+ <date month="October" year="2009"/>
+ <abstract>
+ <t>This document describes an <xref target="RFC4511">LDAP</xref> schema for implementing the
+ <xref target="RFC4120">Kerberos 5</xref>
+ <xref target="I-D.ietf-krb-wg-kdc-model">KDC Information Model</xref>.
+ It also defines additional elements which are not covered by the Information Model,
+ but are already in common use.
+</t>
+ </abstract>
+ </front>
+
+ <middle>
+ <section anchor="background" title="Background and Motivation">
+ <t>Both Kerberos and LDAP are frequently used separately for
+ distributed authentication. They can also be used in combination,
+ but typically their user databases remained separate. This distinction
+ in databases causes unnecessary duplication of data and administration
+ overhead. As such it is desirable for both systems to share a single
+ database. Since the LDAP data model is more general it is most
+ appropriate to store the Kerberos data in LDAP.</t>
+ <t>A number of Kerberos implementations already have support for
+ using LDAP as their KDC backing store. However, each implementation
+ uses its own schema, and the multiple schemas are mutually
+ incompatible. For the sake of interoperability and administrative
+ ease, it is important to define a single standard schema that can
+ be used uniformly by all Kerberos KDC implementations and interoperates
+ with existing LDAP specifications.</t>
+ </section>
+ <section anchor="general" title="General Issues">
+ <section anchor="genera.terms" title="Terminology">
+ <t>The key words "MUST", "SHOULD", and "MAY" used in this document
+ are to be interpreted as described in
+ <xref target="RFC2119"/>.</t>
+ <t>The OIDs defined below are derived from
+<!-- joint-iso-ccitt(2) country(16) us(840) organization(1) Novell(113719) applications(1) kerberos(301)
+ and
+ iso(1) member-body(2) United States(840) mit (113554) infosys(1) ldap(4) attributeTypes(1) Kerberos(6) -->
+ TBD.OID:<vspace blankLines="0"/>
+ KRBSYN = TBD.OID.0<vspace blankLines="0"/>
+ KRBATTR = TBD.OID.1<vspace blankLines="0"/>
+ KRBOC = TBD.OID.2<vspace blankLines="0"/>
+ </t>
+ </section>
+ <section title="Schema">
+ <t>The attributes and classes defined in this document are summarized
+ below.</t>
+ <section anchor="general.attrs" title="Attributes">
+ <t>The following attributes are defined in this document:
+ <list style="empty">
+ <t>
+ krbPrincipalName<vspace blankLines="0"/>
+ krbPrincipalAliases<vspace blankLines="0"/>
+ krbTicketMaxLife<vspace blankLines="0"/>
+ krbTicketMaxRenewal<vspace blankLines="0"/>
+ krbEncSaltTypes<vspace blankLines="0"/>
+ krbRealmName<vspace blankLines="0"/>
+ krbPrincipalRealm<vspace blankLines="0"/>
+ krbKeySet<vspace blankLines="0"/>
+ krbKeyVersion<vspace blankLines="0"/>
+ krbTicketPolicy<vspace blankLines="0"/>
+ krbExtraData<vspace blankLines="0"/>
+ krbPrincNamingAttr<vspace blankLines="0"/>
+ krbPrincContainer<vspace blankLines="0"/>
+ krbPwdPolicy<vspace blankLines="0"/>
+ krbLDAPURI<vspace blankLines="0"/>
+ </t>
+ </list>
+ Additionally, some of the attributes defined in
+ <xref target="I-D.behera-ldap-password-policy">LDAP Password Policy
+ </xref> are required.
+ </t>
+ <t>Note: The MIT/Novell schema includes a number of elements for storing the KDC configuration
+ in LDAP. The Information Model doesn't cover these aspects, so I've omitted them for now.
+ Do we need to add them?</t>
+ </section>
+ <section anchor="general.classes" title="Object Classes">
+ <t>The following object classes are defined in this document:
+ <list style="empty">
+ <t>
+ krbKDCInfo<vspace blankLines="0"/>
+ krbPrincipal<vspace blankLines="0"/>
+ krbRealm<vspace blankLines="0"/>
+ </t>
+ </list>
+ </t>
+ </section>
+ </section>
+ </section>
+ <section anchor="attrdefs" title="Attribute Definitions">
+ <t>This section contains attribute definitions to be implemented
+ by KDCs supporting this schema:
+ <figure title="">
+ <artwork>
+ ( KRBATTR.1
+ NAME 'krbPrincipalName'
+ DESC 'Canonical principal name'
+ EQUALITY caseExactIA5Match
+ SUBSTR caseExactSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( KRBATTR.2
+ NAME 'krbPrincipalAliases'
+ SUP krbPrincipalName )
+ </artwork>
+ </figure>
+ These attributes implement section 6.1.1.1 of the Information Model. The
+ krbPrincipalName attribute contains the canonical name of the principal.
+ Any aliases are stored in the krbPrincipalAliases attribute. Since the
+ krbPrincipalAliases attribute is a subtype of the krbPrincipalName
+ attribute, a search on krbPrincipalName will also search the aliases.
+ </t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBATTR.3
+ NAME 'krbTicketMaxLife'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ This attribute implements section 6.1.1.11 of the Information Model.
+ It holds the maximum ticket lifetime in seconds for a principal.
+ </t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBATTR.4
+ NAME 'krbTicketMaxRenewal'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ This attribute implements section 6.1.1.12 of the Information Model.
+ It holds the maximum time in seconds a ticket may be renewed for.
+ </t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBATTR.5
+ NAME 'krbEncSaltTypes'
+ EQUALITY caseIgnoreMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+ </artwork>
+ </figure>
+ This attribute implements section 6.1.1.13 of the Information Model.
+ Holds the allowed encryption/salt type combinations for this principal.
+ If empty or absent any combination supported by the implementation is allowed.
+ <vspace/>
+ Note that sections 6.1.1.2 thru 6.1.1.10 are implemented using the
+ LDAP Password Policy schema.
+ </t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBATTR.6
+ NAME 'krbRealmName'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( KRBATTR.7
+ NAME 'krbPrincipalRealm'
+ DESC 'DN of krbRealm entry'
+ SUP distinguishedName )
+ </artwork>
+ </figure>
+ These attributes provide information about the current realm. They provide
+ the minimal set of information required to implement section 6.1.3 of the
+ Information Model.
+ </t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBATTR.8
+ NAME 'krbKeyVersion'
+ EQUALITY integerMatch
+ ORDERING integerOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ This attribute implements section 6.2.1.1 of the Information Model.
+ It stores the version number of the current key.
+ </t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBATTR.9
+ NAME 'krbKeySet'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+ </artwork>
+ </figure>
+ This attribute implements sections 6.3.1.1 thru 6.3.1.4 of the Information Model.
+ Sections 6.3.1.5 thru 6.3.1.7 are implemented using the LDAP Password Policy schema.
+ This attribute holds the principal's keys optionally encrypted with the
+ Master Key. The attribute is encoded using <xref target="X.680">ASN.1</xref>
+ <xref target="X.690">DER</xref>.
+ <figure><artwork>
+##### The format of the value for this attribute is explained below,
+##### KrbKeySet ::= SEQUENCE {
+##### kvno [0] UInt32,
+##### mkvno [1] UInt32 OPTIONAL,
+##### keys [2] SEQUENCE OF KrbKey,
+##### ...
+##### }
+#####
+##### KrbKey ::= SEQUENCE {
+##### salt [0] KrbSalt OPTIONAL,
+##### key [1] EncryptionKey,
+##### s2kparams [2] OCTET STRING OPTIONAL,
+##### ...
+##### }
+#####
+##### KrbSalt ::= SEQUENCE {
+##### type [0] Int32,
+##### salt [1] OCTET STRING OPTIONAL
+##### }
+#####
+##### EncryptionKey ::= SEQUENCE {
+##### keytype [0] Int32,
+##### keyvalue [1] OCTET STRING
+##### }
+ </artwork></figure></t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBATTR.10
+ NAME 'krbTicketPolicy'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE )
+ </artwork>
+ </figure>
+ This attribute is related to section 6.4 of the Information Model. It
+ defines the flags that a user is allowed or required to use in a ticket
+ request.
+ <figure><artwork>
+#krb5KDCFlagsSyntax SYNTAX ::= {
+# WITH SYNTAX INTEGER
+#-- initial(0), -- require as-req
+#-- forwardable(1), -- may issue forwardable
+#-- proxiable(2), -- may issue proxiable
+#-- renewable(3), -- may issue renewable
+#-- postdate(4), -- may issue postdatable
+#-- server(5), -- may be server
+#-- client(6), -- may be client
+#-- invalid(7), -- entry is invalid
+#-- require-preauth(8), -- must use preauth
+#-- change-pw(9), -- change password service
+#-- require-hwauth(10), -- must use hwauth
+#-- ok-as-delegate(11), -- as in TicketFlags
+#-- user-to-user(12), -- may use user-to-user auth
+#-- immutable(13) -- may not be deleted
+# ID { 1.3.6.1.4.1.5322.10.0.1 }
+#}
+ </artwork></figure>
+ </t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBATTR.11
+ NAME 'krbExtraData'
+ EQUALITY octetStringMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
+ </artwork></figure>
+ This attribute holds arbitrary data that may be needed by a particular
+ implementation. The values are encoded in ASN.1 DER.
+ <figure><artwork>
+##### The format of the values for this attribute is explained below,
+##### ExtraData ::= SEQUENCE {
+##### tag [0] OCTET STRING,
+##### data [1] OCTET STRING
+##### }
+ </artwork></figure>
+ </t>
+ <t>
+ The following four attributes are outside the scope of the Information Model
+ but may be useful in some deployments.
+ <figure>
+ <artwork>
+ ( KRBATTR.12
+ NAME 'krbPrincNamingAttr'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE )
+ </artwork></figure>
+ This attribute records what attribute will be used to name
+ newly created principal entries.
+ <figure>
+ <artwork>
+ ( KRBATTR.13
+ NAME 'krbPrincContainer'
+ DESC 'DN of container entry for principals'
+ SUP distinguishedName
+ SINGLE-VALUE )
+ </artwork></figure>
+ This attribute points to the container entry under which
+ new principal entries will be created.
+ <figure>
+ <artwork>
+ ( KRBATTR.14
+ NAME 'krbPwdPolicy'
+ DESC 'DN of password policy subentry'
+ SUP distinguishedName
+ SINGLE-VALUE )
+ </artwork></figure>
+ This attribute points to the LDAP password policy subentry
+ containing the policy that should be applied to Kerberos principals.
+
+ Note that in LDAP servers with full subentry support, the subentry's
+ subtree search specification defines what entries the subentry applies
+ to, so this attribute is unnecessary; it is provided merely for
+ informational purposes.
+ <figure>
+ <artwork>
+ ( KRBATTR.15
+ NAME 'krbLDAPURI'
+ DESC 'LDAP search parameters for locating principals'
+ SUP labeledURI )
+ </artwork></figure>
+ This attribute contains LDAP URIs that the KDC will search when
+ locating principals. The URI values must conform to the syntax
+ defined in <xref target="RFC4516"/>. As a special case, the URI
+ prefix "ldap:///" is taken to mean the current LDAP server.
+ </t>
+ </section>
+ <section anchor="classdefs" title="Class Definitions">
+ <t>This section contains class definitions to be implemented by KDCs
+ supporting the schema.</t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBOC.1 NAME 'krbKDCInfo' SUP top AUXILIARY
+ MAY ( krbTicketMaxLife $ krbTicketMaxRenewal $
+ krbEncSaltTypes $ krbTicketPolicy $
+ krbKeySet $ krbKeyVersion ) )
+ </artwork>
+ </figure>
+ <figure>
+ <artwork>
+ ( KRBOC.2 NAME 'krbPrincipal' SUP krbKDCInfo AUXILIARY
+ MUST ( krbPrincipalName )
+ MAY ( krbPrincipalAliases $ krbPrincipalRealm $
+ krbExtraData ) )
+ </artwork>
+ </figure>
+ </t>
+ <t>
+ <figure>
+ <artwork>
+ ( KRBOC.3 NAME 'krbRealm' SUP krbKDCInfo AUXILIARY
+ MUST ( krbRealmName )
+ MAY ( krbPrincNamingAttr $ krbPrincContainer $
+ krbPwdPolicy $ krbLDAPURI ) )
+ </artwork>
+ </figure>
+ Note that in a krbRealm object the krbKeySet and krbKeyVersion
+ attributes actually reflect the Master key for the realm. In this
+ case the krbKeySet's mkvno field and all other optional fields
+ are omitted.
+ </t>
+ </section>
+ <section anchor="impl" title="Implementation Details">
+ <t>Since the LDAP Password Policy is intimately involved in the
+ security mechanisms of this proposal, the directory should be treated
+ as more than just a passive data store. (The KDC can certainly read
+ the policy attributes and evaluate them itself, but that would mean
+ needlessly duplicating all of the functionality that is already
+ implemented in the directory server.) This means that for every
+ Kerberos authentication being serviced, a corresponding LDAP
+ operation must also be performed, in order to allow the password
+ policy mechanisms to operate.</t>
+ <t>The mechanism outlined here assumes that the plain LDAP credentials
+ and the Kerberos credentials are unified (or at least synchronized). In
+ that case, for every incoming Kerberos authentication request, the KDC
+ can issue an LDAP Compare request using the known credentials of
+ the user and the LDAP Password Policy control. The result of the request
+ will carry any relevant error codes if the account is disabled, the
+ password is expired, or various other failures. If preauthentication is
+ in use and the request is invalid, a Compare with known invalid
+ credentials may be used to update the password policy state.</t>
+ <section title="Model Details">
+ <t>A number of data elements described in the Information Model are
+ delegated to the LDAP DSA for management. Details of their
+ usage are described here.</t>
+ <section title="principalNotUsedBefore">
+ <t>Section 6.1.1.2 of the Information Model. This corresponds to the
+ pwdStartTime attribute. If the KDC is using LDAP requests to operate the
+ Password Policy mechanism then it does not need to reference or manipulate
+ this attribute directly.</t>
+ </section>
+ <section title="principalNotUsedAfter">
+ <t>Section 6.1.1.3 of the Information Model. This corresponds to the
+ pwdEndTime attribute. If the KDC is using LDAP requests to operate the
+ Password Policy mechanism then it does not need to reference or manipulate
+ this attribute directly.</t>
+ </section>
+ <section title="principalIsDisabled">
+ <t>Section 6.1.1.4 of the Information Model.
+ If the KDC is using LDAP requests to operate the
+ Password Policy mechanism then it does not need to reference or manipulate
+ this attribute directly. Otherwise, this effect is controlled by setting
+ the pwdStartTime attribute to a value greater than or equal to the
+ pwdEndTime attribute.</t>
+ </section>
+ <section title="principalNumberOfFailedAuthenticationAttempts">
+ <t>Section 6.1.1.5 of the Information Model.
+ If the KDC is using LDAP requests to operate the
+ Password Policy mechanism then it does not need to reference or manipulate
+ this attribute directly. Otherwise, this value is obtained by counting the
+ number of values stored in the pwdFailureTime attribute.</t>
+ </section>
+ <section title="principalLastFailedAuthentication">
+ <t>Section 6.1.1.6 of the Information Model.
+ If the KDC is using LDAP requests to operate the
+ Password Policy mechanism then it does not need to reference or manipulate
+ this attribute directly. Otherwise, this value is obtained by retrieving the
+ values stored in the pwdFailureTime attribute and selecting the most recent value.</t>
+ </section>
+ <section title="principalLastSuccessfulAuthentication">
+ <t>Section 6.1.1.7 of the Information Model. This corresponds to the
+ pwdLastSuccess attribute.
+ If the KDC is using LDAP requests to operate the
+ Password Policy mechanism then it does not need to reference or manipulate
+ this attribute directly.</t>
+ </section>
+ <section title="principalLastCredentialChangeTime">
+ <t>Section 6.1.1.8 of the Information Model. This corresponds to the
+ pwdChangedTime attribute.
+ If the KDC uses the LDAP <xref target="RFC3062">Password Modify</xref> request
+ then it does not need to reference or manipulate
+ this attribute directly.</t>
+ </section>
+ <section title="principalCreateTime">
+ <t>Section 6.1.1.9 of the Information Model. This corresponds to the
+ createTimestamp attribute.
+ The KDC does not need to reference or manipulate this attribute directly.</t>
+ </section>
+ <section title="principalModifyTime">
+ <t>Section 6.1.1.10 of the Information Model. This corresponds to the
+ modifyTimestamp attribute.
+ The KDC does not need to reference or manipulate this attribute directly.</t>
+ </section>
+ </section>
+ <section title="KeySet details">
+ <t>The krbKeySet attribute is multi-valued but it is expected that
+ it will usually only contain one value. During a password change operation
+ the KDC may choose to keep one previous value present to allow currently
+ active clients to continue to operate using the previous key. How long to
+ retain this old password is unspecified here. Note also that the LDAP
+ Password Policy mechanism already has provisions for password history
+ management, so the krbKeySet attribute should not be used for
+ long-term password history tracking.</t>
+ </section>
+ </section>
+ <section anchor="security" title="Security Considerations">
+ <t>This entire document is concerned with an implementation of a secure
+ distributed authentication mechanism. It should be understood that
+ the various keys used here are all sensitive pieces of data and must
+ be adequately protected using access controls and other mechanisms.
+ Likewise all communications between the KDC and DSA must be protected
+ whenever sensitive data is being referenced.</t>
+ <t>In common practice the KDC and DSA have been colocated on a
+ single host and communicated over a local
+ <xref target="I-D.chu-ldap-ldapi">LDAP IPC</xref> session. As such it was
+ implied that the host security was equivalent for both. If a KDC is
+ configured to use a remote DSA, the remote host should be
+ configured with at least the same level of security as the KDC host,
+ and a secure channel MUST be used for the LDAP session.</t>
+ <t>Storing the Master Key in the DSA makes it even more
+ crucial that the LDAP host, service, and data files be adequately
+ protected. Backups of the LDAP database should also be encrypted to
+ protect the integrity of any keys contained therein.</t>
+ </section>
+ <section title="IANA Considerations">
+ <t>In accordance with <xref target="RFC4520"/> the following registrations
+ are requested.</t>
+ <section title="Object Identifiers">
+ <t>[[List of OIDs, registration template goes here...]]</t>
+ </section>
+ <section title="LDAP Descriptors">
+ <t>[[List of Attribute and ObjectClass descriptors, template goes here...]]</t>
+ </section>
+ </section>
+ <section anchor="acks" title="Acknowledgements">
+ <t>Thanks to Simo Sorce from Red Hat Inc. and Love Hörnquist Åstrand
+ from Apple Corp. for their feedback on this document.</t>
+ </section>
+ </middle>
+ <back>
+ <references title="Normative References">
+ &rfc2119;
+ &rfc3062;
+ &rfc4120;
+ &rfc4511;
+ &rfc4516;
+ &rfc4520;
+ &ppolicy;
+ &kdcmodel;
+ <reference anchor="X.680">
+ <front>
+ <title>Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
+ <author>
+ <organization abbrev="ITU-T">
+ International Telecommunications Union</organization>
+ </author>
+ <date month="July" year="2002" />
+ </front>
+ <seriesInfo name="ITU-T Recommendation" value="X.680" />
+ </reference>
+
+ <reference anchor="X.690">
+ <front>
+ <title>Information Technology - ASN.1 encoding rules: Specification of Basic
+ Encoding Rules (BER), Canonical Encoding Rules (CER) and
+ Distinguished Encoding Rules (DER)</title>
+ <author>
+ <organization abbrev="ITU-T">
+ International Telecommunications Union</organization>
+ </author>
+ <date month="July" year="2002" />
+ </front>
+ <seriesInfo name="ITU-T Recommendation" value="X.690" />
+ </reference>
+ </references>
+ <references title="Informative References">
+ &ldapi;
+ </references>
+ </back>
+</rfc>
projects / openldap / blobdiff