upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2025-12-24 00:29:35 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Add Steven's I-Ds on LDAP/X.500 admin models

Browse source 
Correct naming of older drafts
This commit is contained in:
Kurt Zeilenga 2002-09-23 04:35:05 +00:00
parent d0a4fee37a
commit 044b39f4ec
7 changed files with 4663 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

0
doc/drafts/draft-leach-uuids-guids-01.txt → doc/drafts/draft-leach-uuids-guids-xx.txt
View file

451
doc/drafts/draft-legg-ldap-acm-admin-xx.txt Normal file
View file

@ -0,0 +1,451 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-acm-admin-01.txt Adacel Technologies
Intended Category: Standards Track September 18, 2002
Access Control Administration in LDAP
Copyright (C) The Internet Society (2002). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Distribution of this document is unlimited. Comments should be sent
to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
author.
This Internet-Draft expires on 18 March 2003.
1. Abstract
This document adapts the X.500 directory administrative model, as it
pertains to access control administration, for use by the Lightweight
Directory Access Protocol. The administrative model partitions the
Directory Information Tree for various aspects of directory data
administration, e.g. subschema, access control and collective
attributes. This document provides the particular definitions that
support access control administration, but does not define a
particular access control scheme.
Legg Expires 18 March 2003 [Page 1]
INTERNET-DRAFT Access Control Administration September 18, 2002
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 [RFC2119].
2. Table of Contents
1. Abstract .................................................... 1
2. Table of Contents ........................................... 2
3. Introduction ................................................ 2
4. Access Control Administrative Areas ......................... 3
5. Access Control Scheme Indication ............................ 3
6. Access Control Information .................................. 4
7. Access Control Subentries ................................... 4
8. Applicable Access Control Information ....................... 5
9. Security Considerations ..................................... 5
10. Acknowledgements ........................................... 6
11. Normative References ....................................... 6
12. Informative References ..................................... 6
13. Copyright Notice ........................................... 7
14. Author's Address ........................................... 7
3. Introduction
This document adapts the X.500 directory administrative model [X501],
as it pertains to access control administration, for use by the
Lightweight Directory Access Protocol (LDAP) [RFC2251].
The administrative model [ADMIN] partitions the Directory Information
Tree (DIT) for various aspects of directory data administration, e.g.
subschema, access control and collective attributes. The parts of
the administrative model that apply to every aspect of directory data
administration are described in [ADMIN]. This document describes the
administrative framework for access control.
An access control scheme describes the means by which access to
directory information, and potentially to access rights themselves,
may be controlled. This document describes the framework for
employing access control schemes but does not define a particular
access control scheme. Two access control schemes known as Basic
Access Control and Simplified Access Control are defined by [BAC].
Other access control schemes MAY be defined by other documents.
Schema definitions are provided using LDAP description formats
[RFC2252]. Note that the LDAP descriptions have been rendered with
additional white-space and line breaks for the sake of readability.
Legg Expires 18 March 2003 [Page 2]
INTERNET-DRAFT Access Control Administration September 18, 2002
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
4. Access Control Administrative Areas
The specific administrative area [ADMIN] for access control is termed
an Access Control Specific Area (ACSA). The root of the ACSA is
termed an Access Control Specific Point (ACSP) and is represented in
the DIT by an administrative entry [ADMIN] which includes
accessControlSpecificArea as a value of its administrativeRole
operational attribute [SUBENTRY].
An ACSA MAY be partitioned into subtrees termed inner administrative
areas [ADMIN]. Each such inner area is termed an Access Control
Inner Area (ACIA). The root of the ACIA is termed an Access Control
Inner Point (ACIP) and is represented in the DIT by an administrative
entry which includes accessControlInnerArea as a value of its
administrativeRole operational attribute.
An administrative entry can never be both an ACSP and an ACIP. The
corresponding values can therefore never be present simultaneously in
the administrativeRole attribute.
Each entry necessarily falls within one and only one ACSA. Each such
entry may also fall within one or more ACIAs nested inside the ACSA
containing the entry.
An ACSP or ACIP has zero, one or more subentries that contain Access
Control Information (ACI).
5. Access Control Scheme Indication
The access control scheme (e.g. Basic Access Control [BAC]) in force
in an ACSA is indicated by the accessControlScheme operational
attribute contained in the administrative entry for the relevant
ACSP.
The LDAP description [RFC2252] for the accessControlScheme
operational attribute is:
( 2.5.24.1 NAME 'accessControlScheme'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE USAGE directoryOperation )
An access control scheme conforming to the access control framework
Legg Expires 18 March 2003 [Page 3]
INTERNET-DRAFT Access Control Administration September 18, 2002
described in this document MUST define a distinct OBJECT IDENTIFIER
value to identify it through the accessControlScheme attribute.
Only administrative entries for ACSPs are permitted to contain an
accessControlScheme attribute. If the accessControlScheme attribute
is absent from a given ACSP, the access control scheme in force in
the corresponding ACSA, and its effect on operations, results and
errors, is implementation defined.
Any entry or subentry in an ACSA is permitted to contain ACI if and
only if such ACI is permitted by, and consistent with, the access
control scheme identified by the value of the accessControlScheme
attribute of the ACSP.
6. Access Control Information
There are three categories of Access Control Information (ACI):
entry, subentry and prescriptive.
Entry ACI applies to only the entry or subentry in which it appears,
and the contents thereof. Subject to the access control scheme, any
entry or subentry MAY hold entry ACI.
Subentry ACI applies to only the subentries of the administrative
entry in which it appears. Subject to the access control scheme, any
administrative entry, for any aspect of administration, MAY hold
subentry ACI.
Prescriptive ACI applies to all the entries within a subtree or
subtree refinement of an administrative area (either an ACSA or an
ACIA), as defined by the subtreeSpecification attribute of the
subentry in which it appears. Prescriptive ACI is only permitted in
subentries of an ACSP or ACIP. Prescriptive ACI in the subentries of
a particular administrative point never applies to the same or any
other subentry of that administrative point, but does apply to the
subentries of subordinate administrative points, where those
subentries are within the subtree or subtree refinement.
7. Access Control Subentries
Each subentry which contains prescriptive ACI MUST have
accessControlSubentry as a value of its objectClass attribute. Such
a subentry is called an access control subentry.
The LDAP description [RFC2252] for the accessControlSubentry
auxiliary object class is:
Legg Expires 18 March 2003 [Page 4]
INTERNET-DRAFT Access Control Administration September 18, 2002
( 2.5.17.1 NAME 'accessControlSubentry' AUXILIARY )
A subentry of this object class MUST contain at least one
prescriptive ACI attribute of a type consistent with the value of the
accessControlScheme attribute of the corresponding ACSP.
The subtree or subtree refinement for an access control subentry is
termed a Directory Access Control Domain (DACD). A DACD can contain
zero entries, and can encompass entries that have not yet been added
to the DIT, but does not extend beyond the scope of the ACSA or ACIA
with which it is associated.
Since a subtreeSpecification may define a subtree refinement, DACDs
within a given ACSA may arbitrarily overlap.
8. Applicable Access Control Information
Although particular items of ACI may specify attributes or values as
the protected items, ACI is logically associated with entries.
The ACI that is considered in access control decisions regarding an
entry includes:
(1) Entry ACI from that particular entry.
(2) Prescriptive ACI from access control subentries whose DACDs
contain the entry. Each of these access control subentries is
necessarily either a subordinate of the ACSP for the ACSA
containing the entry, or a subordinate of the ACIP for an ACIA
that contains the entry.
The ACI that is considered in access control decisions regarding a
subentry includes:
(1) Entry ACI from that particular subentry.
(2) Prescriptive ACI from access control subentries whose DACDs
contain the subentry, excluding those belonging to the same
administrative point as the subentry for which the decision is
being made.
(3) Subentry ACI from the administrative point associated with the
subentry.
9. Security Considerations
Legg Expires 18 March 2003 [Page 5]
INTERNET-DRAFT Access Control Administration September 18, 2002
This document defines a framework for employing an access control
scheme, i.e. the means by which access to directory information and
potentially to access rights themselves may be controlled, but does
not itself define any particular access control scheme. The degree
of protection provided, and any security risks, are determined by the
provisions of the access control schemes (defined elsewhere) making
use of this framework.
Security considerations that apply to directory administration in
general [ADMIN] also apply to access control administration.
10. Acknowledgements
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[ADMIN] Legg, S., "Directory Administrative Model in LDAP",
draft-legg-ldap-admin-xx.txt, a work in progress,
September 2002.
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
August 2002.
12. Informative References
[BAC] Legg, S., "Basic and Simplified Access Control in LDAP",
draft-legg-ldap-acm-bac-xx.txt, a work in progress,
September 2002.
[COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
draft-zeilenga-ldap-collective-xx.txt, a work in progress,
August 2002.
Legg Expires 18 March 2003 [Page 6]
INTERNET-DRAFT Access Control Administration September 18, 2002
[X501] ITU-T Recommendation X.501 (02/2001), Information
technology - Open Systems Interconnection - The Directory:
Models
13. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Author's Address
Steven Legg
Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
EMail: steven.legg@adacel.com.au
15. Appendix A - Changes From Previous Drafts
Legg Expires 18 March 2003 [Page 7]
INTERNET-DRAFT Access Control Administration September 18, 2002
15.1 Changes in Draft 01
Section 4 has been extracted to become a separate Internet draft,
draft-legg-ldap-admin-00.txt. The subsections of Section 5 have
become the new Sections 4 to 8. Editorial changes have been made to
accommodate this split. No technical changes have been introduced.
Legg Expires 18 March 2003 [Page 8]

395
doc/drafts/draft-legg-ldap-admin-xx.txt Normal file
View file

@ -0,0 +1,395 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-admin-00.txt Adacel Technologies
Intended Category: Standards Track September 18, 2002
Directory Administrative Model in LDAP
Copyright (C) The Internet Society (2002). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Distribution of this document is unlimited. Comments should be sent
to the LDUP working group mailing list <ietf-ldup@imc.org> or to the
author.
This Internet-Draft expires on 18 March 2003.
1. Abstract
This document adapts the X.500 directory administrative model for use
by the Lightweight Directory Access Protocol. The administrative
model partitions the Directory Information Tree for various aspects
of directory data administration, e.g. subschema, access control and
collective attributes. The generic framework that applies to every
aspect of administration is described in this document. The
definitions that apply for a specific aspect of administration, e.g.
access control administration, are described in other documents.
Legg Expires 18 March 2003 [Page 1]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
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 [RFC2119].
2. Table of Contents
1. Abstract .................................................... 1
2. Table of Contents ........................................... 2
3. Introduction ................................................ 2
4. Administrative Areas ........................................ 2
5. Autonomous Administrative Areas ............................. 3
6. Specific Administrative Areas ............................... 3
7. Inner Administrative Areas .................................. 4
8. Administrative Entries ...................................... 5
9. Security Considerations ..................................... 5
10. Acknowledgements ........................................... 5
11. Normative References ....................................... 5
12. Informative References ..................................... 6
13. Copyright Notice ........................................... 6
14. Author's Address ........................................... 6
3. Introduction
This document adapts the X.500 directory administrative model [X501]
for use by the Lightweight Directory Access Protocol (LDAP)
[RFC2251]. The administrative model partitions the Directory
Information Tree (DIT) for various aspects of directory data
administration, e.g. subschema, access control and collective
attributes. This document provides the definitions for the generic
parts of the administrative model that apply to every aspect of
directory data administration.
Sections 4 to 8, in conjunction with [SUBENTRY], describe the means
by which administrative authority is aportioned and exercised in the
DIT.
Aspects of administration that conform to the administrative model
described in this document are detailed elsewhere, e.g. access
control administration is described in [ACA] and collective attribute
administration is described in [COLLECT].
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
4. Administrative Areas
Legg Expires 18 March 2003 [Page 2]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
An administrative area is a subtree of the DIT considered from the
perspective of administration. The root entry of the subtree is an
administrative point. An administrative point is represented by an
entry holding an administrativeRole attribute [SUBENTRY]. The values
of this attribute identify the kind of administrative point.
5. Autonomous Administrative Areas
The DIT may be partitioned into one or more non-overlapping subtrees
termed autonomous administrative areas. It is expected that the
entries in an autonomous administrative area are all administered by
the same administrative authority.
An administrative authority may be responsible for several autonomous
administrative areas in separated parts of the DIT but it SHOULD NOT
arbitrarily partition the collection of entries under its control
into autonomous administrative areas (thus creating adjacent
autonomous areas administered by the same authority).
The root entry of an autonomous administrative area's subtree is
called an autonomous administrative point. An autonomous
administrative area extends from its autonomous administrative point
downwards until another autonomous administrative point is
encountered, at which point another autonomous administrative area
begins.
6. Specific Administrative Areas
Entries in an administrative area may be considered in terms of a
specific administrative function. When viewed in this context, an
administrative area is termed a specific administrative area.
Examples of specific administrative areas are subschema specific
administrative areas, access control specific areas and collective
attribute specific areas.
An autonomous administrative area may be considered as implicitly
defining a single specific administrative area for each specific
aspect of administration. In this case, there is a precise
correspondence between each such specific administrative area and the
autonomous administrative area.
Alternatively, for each specific aspect of administration, the
autonomous administrative area may be partitioned into
non-overlapping specific administrative areas.
Legg Expires 18 March 2003 [Page 3]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
If so partitioned for a particular aspect of administration, each
entry of the autonomous administrative area is contained in one and
only one specific administrative area for that aspect, i.e. specific
administrative areas do not overlap.
The root entry of a specific administrative area's subtree is called
a specific administrative point. A specific administrative area
extends from its specific administrative point downwards until
another specific administrative point of the same administrative
aspect is encountered, at which point another specific administrative
area begins. Specific administrative areas are always bounded by the
autonomous administrative area they partition.
Where an autonomous administrative area is not partitioned for a
specific aspect of administration, the specific administrative area
for that aspect coincides with the autonomous administrative area.
In this case, the autonomous administrative point is also the
specific administrative point for this aspect of administration. A
particular administrative point may be the root of an autonomous
administrative area and may be the root of one or more specific
administrative areas for different aspects of administration.
It is not necessary for an administrative point to represent each
specific aspect of administrative authority. For example, there
might be an administrative point, subordinate to the root of the
autonomous administrative area, which is used for access control
purposes only.
7. Inner Administrative Areas
For some aspects of administration, e.g. access control or collective
attributes, inner administrative areas may be defined within the
specific administrative areas, to allow a limited form of delegation,
or for administrative or operational convenience.
An inner administrative area may be nested within another inner
administrative area. The rules for nested inner areas are defined as
part of the definition of the specific administrative aspect for
which they are allowed.
The root entry of an inner administrative area's subtree is called an
inner administrative point. An inner administrative area (within a
specific administrative area) extends from its inner administrative
point downwards until a specific administrative point of the same
administrative aspect is encountered. An inner administrative area
is bounded by the specific administrative area within which it is
defined.
Legg Expires 18 March 2003 [Page 4]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
8. Administrative Entries
An entry located at an administrative point is an administrative
entry. Administrative entries MAY have subentries [SUBENTRY] as
immediate subordinates. The administrative entry and its associated
subentries are used to control the entries encompassed by the
associated administrative area. Where inner administrative areas are
used, the scopes of these areas may overlap. Therefore, for each
specific aspect of administrative authority, a definition is required
of the method of combination of administrative information when it is
possible for entries to be included in more than one subtree or
subtree refinement associated with an inner area defined for that
aspect.
9. Security Considerations
This document defines a generic framework for employing policy of
various kinds, e.g. access controls, to entries in the DIT. Such
policy can only be correctly enforced at a directory server holding a
replica of a portion of the DIT if the administrative entries for
administrative areas that overlap the portion of the DIT being
replicated, and the subentries of those administrative entries
relevant to any aspect of policy that is required to be enforced at
the replica, are included in the replicated information.
Administrative entries and subentries SHOULD be protected from
unauthorized examination or changes by appropriate access controls.
10. Acknowledgements
This document is derived from, and duplicates substantial portions
of, Sections 4 and 8 of [X501].
11. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[SUBENTRY] Zeilenga, K. and S. Legg, "Subentries in LDAP",
draft-zeilenga-ldap-subentry-xx.txt, a work in progress,
August 2002.
Legg Expires 18 March 2003 [Page 5]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
12. Informative References
[ACA] Legg, S., "Access Control Administration in LDAP",
draft-legg-ldap-acm-admin-xx.txt, a work in progress,
September 2002.
[COLLECT] Zeilenga, K., "Collective Attributes in LDAP",
draft-zeilenga-ldap-collective-xx.txt, a work in progress,
August 2002.
[X501] ITU-T Recommendation X.501 (02/2001), Information
technology - Open Systems Interconnection - The Directory:
Models
13. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Author's Address
Steven Legg
Adacel Technologies Ltd.
Legg Expires 18 March 2003 [Page 6]
INTERNET-DRAFT Directory Administrative Model September 18, 2002
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
EMail: steven.legg@adacel.com.au
15. Appendix A - Changes From Previous Drafts
This document reproduces Section 4 from
draft-legg-ldap-acm-admin-00.txt as a standalone document. All
changes made are purely editorial. No technical changes have been
introduced.
Legg Expires 18 March 2003 [Page 7]

619
doc/drafts/draft-legg-ldap-gser-abnf-xx.txt Normal file
View file

@ -0,0 +1,619 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-gser-abnf-04.txt Adacel Technologies
Intended Category: Informational August 19, 2002
Common Elements of GSER Encodings
Copyright (C) The Internet Society (2002). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Distribution of this document is unlimited. Comments should be sent
to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
or to the author.
This Internet-Draft expires on 19 February 2002.
1. Abstract
The Generic String Encoding Rules (GSER) describe a human readable
text encoding for an ASN.1 value of any ASN.1 type. Specifications
making use of GSER may wish to provide an equivalent ABNF description
of the GSER encoding for a particular ASN.1 type as a convenience for
implementors. This document supports such specifications by
providing equivalent ABNF for the GSER encodings for ASN.1 types
commonly occuring in Lightweight Directory Access Protocol (LDAP)
syntaxes.
Legg Expires 19 February 2002 [Page 1]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
2. Table of Contents
1. Abstract .................................................... 1
2. Table of Contents ........................................... 2
3. Introduction ................................................ 2
4. Conventions ................................................. 2
5. Separators .................................................. 2
6. ASN.1 Built-in Types ........................................ 3
7. ASN.1 Restricted String Types ............................... 7
8. Directory ASN.1 Types ....................................... 8
9. Security Considerations ..................................... 9
10. Normative References ....................................... 10
11. Informative References ..................................... 10
12. Copyright Notice ........................................... 10
13. Author's Address ........................................... 11
3. Introduction
The Generic String Encoding Rules (GSER) defined in [9] define a
human readable text encoding, based on ASN.1 [7] value notation, for
an ASN.1 value of any ASN.1 type. Specifications making use of GSER
may wish to provide a non-normative equivalent ABNF [3] description
of the GSER encoding for a particular ASN.1 type as a convenience for
implementors unfamiliar with ASN.1. This document supports such
specifications by providing equivalent ABNF for the GSER encodings
for ASN.1 types commonly occuring in LDAP [8] or X.500 [10] attribute
and assertion syntaxes, as well as equivalent ABNF for the GSER
encodings for the ASN.1 built-in types.
The ABNF given in this document does not replace or alter GSER in any
way. If there is a discrepancy between the ABNF specified here and
the encoding defined by GSER in [9] then [9] is to be taken as
definitive.
4. Conventions
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 [1].
5. Separators
Certain separators are commonly used in constructing equivalent ABNF
for SET and SEQUENCE types.
Legg Expires 19 February 2002 [Page 2]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
sp = *%x20 ; zero, one or more space characters
msp = 1*%x20 ; one or more space characters
sep = [ "," ]
The <sep> rule is used in the ABNF description of the encoding for
ASN.1 SET or SEQUENCE types where all the components are either
OPTIONAL or DEFAULT. It encodes to an empty string if and only if
the immediately preceding character in the encoding is "{", i.e. it
is only empty for the first optional component actually present in
the SET or SEQUENCE value being encoded.
6. ASN.1 Built-in Types
This section describes the GSER encoding of values of the ASN.1
built-in types, except for the restricted character string types.
The <BIT-STRING> rule describes the GSER encoding of values of the
BIT STRING type without a named bit list.
BIT-STRING = bstring / hstring
If the number of bits in a BIT STRING value is a multiple of four the
<hstring> form of <BIT-STRING> MAY be used. The <bstring> form of
<BIT-STRING> is used otherwise. The <bstring> rule encodes each bit
as the character "0" or "1" in order from the first bit to the last
bit. The <hstring> rule encodes each group of four bits as a
hexadecimal number where the first bit is the most significant. An
odd number of hexadecimal digits is permitted.
hstring = squote *hexadecimal-digit squote %x48 ; '...'H
hexadecimal-digit = %x30-39 / ; "0" to "9"
%x41-46 ; "A" to "F"
bstring = squote *binary-digit squote %x42 ; '...'B
binary-digit = "0" / "1"
squote = %x27 ; ' (single quote)
The <BOOLEAN> rule describes the GSER encoding of values of the
BOOLEAN type.
BOOLEAN = %x54.52.55.45 / ; "TRUE"
%x46.41.4C.53.45 ; "FALSE"
The <CHARACTER-STRING> rule describes the GSER encoding of values of
the associated type for the unrestricted CHARACTER STRING type.
Legg Expires 19 February 2002 [Page 3]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
CHARACTER-STRING = "{" sp id-identification msp Identification ","
sp id-data-value msp OCTET-STRING
sp "}"
id-identification = %x69.64.65.6E.74.69.66.69.63.61.74.69.6F.6E
; "identification"
id-data-value = %x64.61.74.61.2D.76.61.6C.75.65 ; "data-value"
Identification = ( id-syntaxes ":" Syntaxes ) /
( id-syntax ":" OBJECT-IDENTIFIER ) /
( id-presentation-context-id ":" INTEGER ) /
( id-context-negotiation ":"
ContextNegotiation ) /
( id-transfer-syntax ":" OBJECT-IDENTIFIER ) /
( id-fixed ":" NULL )
id-syntaxes = %x73.79.6E.74.61.78.65.73
; "syntaxes"
id-syntax = %x73.79.6E.74.61.78 ; "syntax"
id-presentation-context-id = %x70.72.65.73.65.6E.74.61.74.69.6F.6E
%x2D.63.6F.6E.74.65.78.74.2D.69.64
; "presentation-context-id"
id-context-negotiation = %x63.6F.6E.74.65.78.74.2D.6E.65.67.6F
%x74.69.61.74.69.6F.6E
; "context-negotiation"
id-transfer-syntax = %x74.72.61.6E.73.66.65.72.2D.73.79.6E
%x74.61.78 ; "transfer-syntax"
id-fixed = %x66.69.78.65.64 ; "fixed"
Syntaxes = "{" sp id-abstract msp OBJECT-IDENTIFIER ","
sp id-transfer msp OBJECT-IDENTIFIER
sp "}"
id-abstract = %x61.62.73.74.72.61.63.74 ; "abstract"
id-transfer = %x74.72.61.6E.73.66.65.72 ; "transfer"
ContextNegotiation = "{" sp id-presentation-context-id msp
INTEGER ","
sp id-transfer-syntax msp
OBJECT-IDENTIFIER
sp "}"
The <INTEGER> rule describes the GSER encoding of values of the
INTEGER type without a named number list. The <INTEGER-0-MAX> rule
describes the GSER encoding of values of the constrained type INTEGER
(0..MAX). The <INTEGER-1-MAX> rule describes the GSER encoding of
values of the constrained type INTEGER (1..MAX).
INTEGER = "0" / positive-number / ("-" positive-number)
Legg Expires 19 February 2002 [Page 4]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
INTEGER-0-MAX = "0" / positive-number
INTEGER-1-MAX = positive-number
positive-number = non-zero-digit *decimal-digit
decimal-digit = %x30-39 ; "0" to "9"
non-zero-digit = %x31-39 ; "1" to "9"
The <EMBEDDED-PDV> rule describes the GSER encoding of values of the
associated type for the EMBEDDED PDV type.
EMBEDDED-PDV = "{" sp id-identification msp Identification
[ "," sp id-data-value-descriptor msp
ObjectDescriptor ]
"," sp id-data-value msp OCTET-STRING
sp "}"
id-data-value-descriptor = %x64.61.74.61.2D.76.61.6C.75.65.2D.64
%x65.73.63.72.69.70.74.6F.72
; "data-value-descriptor"
The <EXTERNAL> rule describes the GSER encoding of values of the
associated type for the EXTERNAL type.
EXTERNAL = "{" sp id-identification msp E-Identification
[ "," sp id-data-value-descriptor msp
ObjectDescriptor ]
"," sp id-data-value msp OCTET-STRING
sp "}"
E-Identification = ( id-syntax ":" OBJECT-IDENTIFIER ) /
( id-presentation-context-id ":" INTEGER ) /
( id-context-negotiation ":"
ContextNegotiation )
The <NULL> rule describes the GSER encoding of values of the NULL
type.
NULL = %x4E.55.4C.4C ; "NULL"
The <OBJECT-IDENTIFIER> rule describes the GSER encoding of values of
the OBJECT IDENTIFIER type.
OBJECT-IDENTIFIER = numeric-oid / descr
numeric-oid = oid-component 1*( "." oid-component )
oid-component = "0" / positive-number
An OBJECT IDENTIFIER value is encoded using either the dotted decimal
representation or an object descriptor name, i.e. <descr>. The
<descr> rule is described in [4]. An object descriptor name is
Legg Expires 19 February 2002 [Page 5]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
potentially ambiguous and should be used with care.
The <OCTET-STRING> rule describes the GSER encoding of values of the
OCTET STRING type.
OCTET-STRING = hstring
The octets are encoded in order from the first octet to the last
octet. Each octet is encoded as a pair of hexadecimal digits where
the first digit corresponds to the four most significant bits of the
octet. If the hexadecimal string does not have an even number of
digits the four least significant bits in the last octet are assumed
to be zero.
The <REAL> rule describes the GSER encoding of values of the REAL
type.
REAL = "0" ; zero
/ PLUS-INFINITY ; positive infinity
/ MINUS-INFINITY ; negative infinity
/ realnumber ; positive base 10 REAL value
/ ( "-" realnumber ) ; negative base 10 REAL value
/ real-sequence-value ; non-zero base 2 or 10 REAL value
PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
; "PLUS-INFINITY"
MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
; "MINUS-INFINITY"
realnumber = mantissa exponent
mantissa = (positive-number [ "." *decimal-digit ])
/ ( "0." *("0") positive-number )
exponent = "E" ( "0" / ([ "-" ] positive-number))
real-sequence-value = "{" sp id-mantissa msp INTEGER ","
sp id-base msp ( "2" / "10" ) ","
sp id-exponent msp INTEGER sp "}"
id-mantissa = %x6D.61.6E.74.69.73.73.61 ; "mantissa"
id-base = %x62.61.73.65 ; "base"
id-exponent = %x65.78.70.6F.6E.65.6E.74 ; "exponent"
A value of the REAL type MUST be encoded as "0" if it is zero.
The <RELATIVE-OID> rule describes the GSER encoding of values of the
RELATIVE-OID type.
RELATIVE-OID = oid-component *( "." oid-component )
Legg Expires 19 February 2002 [Page 6]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
7. ASN.1 Restricted String Types
This section describes the GSER encoding of values of the ASN.1
restricted character string types. The characters of a value of a
restricted character string type are always encoded as a UTF8
character string between double quotes. For some of the ASN.1 string
types this requires a translation to or form the UTF8 encoding. Some
of the ASN.1 string types permit only a subset of the characters
representable in UTF8. Any double quote characters in the character
string, where allowed by the character set, are escaped by being
repeated.
The <UTF8String> rule describes the GSER encoding of values of the
UTF8String type. The characters of this string type do not require
any translation before being encoded.
UTF8String = StringValue
StringValue = dquote *SafeUTF8Character dquote
dquote = %x22 ; " (double quote)
SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote
dquote dquote / ; escaped double quote
%xC0-DF %x80-BF / ; 2 byte UTF8 character
%xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character
%xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character
%xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character
%xFC-FD 5(%x80-BF) ; 6 byte UTF8 character
The <NumericString>, <PrintableString>, <VisibleString>,
<ISO646String>, <IA5String>, <GeneralizedTime> and <UTCTime> rules
describe the GSER encoding of values of the correspondingly named
ASN.1 types. The characters of these string types are compatible
with UTF8 and do not require any translation before being encoded.
The GeneralizedTime and UTCTime types use the VisibleString character
set, but have a strictly defined format.
NumericString = dquote *(decimal-digit / space) dquote
space = %x20
PrintableString = dquote *PrintableCharacter dquote
PrintableCharacter = decimal-digit / space
/ %x41-5A ; A to Z
/ %x61-7A ; a to z
/ %x27-29 ; ' ( )
/ %x2B-2F ; + , - . /
/ %x3A ; :
/ %x3D ; =
Legg Expires 19 February 2002 [Page 7]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
/ %x3F ; ?
ISO646String = VisibleString
VisibleString = dquote *SafeVisibleCharacter dquote
SafeVisibleCharacter = %x20-21
/ %x23-7E ; printable ASCII minus dquote
/ dquote dquote ; escaped double quote
IA5String = dquote *SafeIA5Character dquote
SafeIA5Character = %x00-21 / %x23-7F ; ASCII minus dquote
/ dquote dquote ; escaped double quote
UTCTime = dquote 10(decimal-digit) [2(decimal-digit)]
[ "Z" / u-differential ] dquote
u-differential = ( "-" / "+" ) 4(decimal-digit)
GeneralizedTime = dquote 10(decimal-digit)
*2(2(decimal-digit))
fraction [ "Z" / g-differential ] dquote
fraction = ( "." / "," ) 1*decimal-digit
g-differential = ( "-" / "+" ) 1*2(2(decimal-digit))
The <BMPString> and <UniversalString> rules describe the GSER
encoding of values of the BMPString and UniversalString types
respectively. BMPString (UCS-2) and UniversalString (UCS-4) values
are translated into UTF8 [6] character strings before being encoded
according to <StringValue>.
BMPString = StringValue
UniversalString = StringValue
The <TeletexString>, <T61String>, <VideotexString>, <GraphicString>,
<GeneralString> and <ObjectDescriptor> rules describe the GSER
encoding of values of the correspondingly named ASN.1 types. Values
of these string types are translated into UTF8 character strings
before being encoded according to <StringValue>. The
ObjectDescriptor type uses the GraphicString character set.
TeletexString = StringValue
T61String = StringValue
VideotexString = StringValue
GraphicString = StringValue
GeneralString = StringValue
ObjectDescriptor = GraphicString
8. Directory ASN.1 Types
This section describes the GSER encoding of values of selected ASN.1
Legg Expires 19 February 2002 [Page 8]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
types defined for LDAP and X.500. The ABNF rule names beginning with
uppercase letters describe the GSER encoding of values of the ASN.1
type with the same name.
AttributeType = OBJECT-IDENTIFIER
The characters of a DirectoryString are translated into UTF8
characters as required before being encoded between double quotes
with any embedded double quotes escaped by being repeated.
DirectoryString = dquote *SafeUTF8Character dquote
The <RDNSequence> rule describes the GSER encoding of values of the
RDNSequence type, which is syntactically equivalent to the
DistinguishedName and LocalName types. The <RDNSequence> rule
encodes a name as an LDAPDN character string between double quotes.
The character string is first derived according to the
<distinguishedName> rule in Section 3 of [5], and then it is encoded
between double quotes with any embedded double quotes escaped by
being repeated.
DistinguishedName = RDNSequence
LocalName = RDNSequence
RDNSequence = dquote *SafeUTF8Character dquote
The <RelativeDistinguishedName> rule describes the GSER encoding of
values of the RelativeDistinguishedName type that are not part of an
RDNSequence value. The <RelativeDistinguishedName> rule encodes an
RDN as a double quoted string containing the RDN 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 quote characters are escaped by being repeated.
This resulting string is output between double quotes.
RelativeDistinguishedName = dquote *SafeUTF8Character dquote
The <ORAddress> rule encodes an X.400 address as an IA5 character
string between double quotes. The character string is first derived
according to Section 4.1 of [2], and then any embedded double quotes
are escaped by being repeated. This resulting string is output
between double quotes.
ORAddress = dquote *SafeIA5Character dquote
9. Security Considerations
GSER, and therefore the ABNF encodings described in this document, do
Legg Expires 19 February 2002 [Page 9]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
not necessarily enable the exact octet encoding of values of the
TeletexString, VideotexString, GraphicString or GeneralString types
to be reconstructed, so a transformation from DER to GSER and back to
DER may not reproduce the original DER encoding. This has
consequences for the verification of digital signatures.
10. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[7] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
Information Technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
11. Informative References
[8] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[9] Legg, S., "Generic String Encoding Rules for ASN.1 Types",
draft-legg-ldap-gser-xx.txt, a work in progress, August 2002.
[10] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
12. Copyright Notice
Legg Expires 19 February 2002 [Page 10]
INTERNET-DRAFT Common Elements of GSER Encodings August 19, 2002
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
13. Author's Address
Steven Legg
Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
EMail: steven.legg@adacel.com.au
Legg Expires 19 February 2002 [Page 11]

899
doc/drafts/draft-legg-ldap-gser-xx.txt Normal file
View file

@ -0,0 +1,899 @@
INTERNET-DRAFT S. Legg
draft-legg-ldap-gser-01.txt Adacel Technologies
Intended Category: Standard Track August 19, 2002
Generic String Encoding Rules for ASN.1 Types
Copyright (C) The Internet Society (2002). All Rights Reserved.
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Distribution of this document is unlimited. Comments should be sent
to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
or to the author.
This Internet-Draft expires on 19 February 2002.
1. Abstract
This document defines a set of Abstract Syntax Notation One (ASN.1)
encoding rules, called the Generic String Encoding Rules, that
produce a human readable text encoding for values of any given ASN.1
data type.
Legg Expires 19 February 2002 [Page 1]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
2. Table of Contents
1. Abstract ...................................................... 1
2. Table of Contents ............................................. 2
3. Introduction .................................................. 2
4. Conventions ................................................... 3
5. Generic String Encoding Rules ................................. 3
5.1 Type Referencing Notations ................................ 4
5.2 Restricted Character String Types ......................... 4
5.3 ChoiceOfStrings Types ..................................... 5
5.4 Identifiers ............................................... 7
5.5 BIT STRING ................................................ 7
5.6 BOOLEAN ................................................... 8
5.7 ENUMERATED ................................................ 8
5.8 INTEGER ................................................... 8
5.9 NULL ...................................................... 8
5.10 OBJECT IDENTIFIER and RELATIVE-OID ....................... 9
5.11 OCTET STRING ............................................. 9
5.12 CHOICE ................................................... 9
5.13 SEQUENCE and SET ......................................... 10
5.14 SEQUENCE OF and SET OF ................................... 11
5.15 CHARACTER STRING ......................................... 11
5.16 EMBEDDED PDV ............................................. 11
5.17 EXTERNAL ................................................. 11
5.18 INSTANCE OF .............................................. 12
5.19 REAL ..................................................... 12
5.20 Variant Encodings ........................................ 12
6. GSER Transfer Syntax .......................................... 13
7. Security Considerations ....................................... 13
8. Normative References .......................................... 13
9. Informative References ........................................ 14
10. Copyright Notice ............................................. 15
11. Author's Address ............................................. 15
3. Introduction
This document defines a set of ASN.1 [8] encoding rules, called the
Generic String Encoding Rules or GSER, that produce a human readable
UTF8 [6] character string encoding of ASN.1 values of any given
arbitrary ASN.1 type.
Note that "ASN.1 value" does not mean a BER [17] encoded value. The
ASN.1 value is an abstract concept that is independent of any
particular encoding. BER is just one possible encoding of an ASN.1
value.
GSER is based on ASN.1 value notation [8], with changes to
Legg Expires 19 February 2002 [Page 2]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
accommodate the notation's use as a transfer syntax, and to support
well established ad-hoc string encodings for LDAP [13] directory data
types.
Though primarily intended for defining the LDAP-specific encoding of
new LDAP attribute syntaxes and assertion syntaxes, these encoding
rules could also be used in other domains where human readable
renderings of ASN.1 values would be useful.
Referencing the Generic String Encoding Rules (GSER) is sufficient to
define a human readable text encoding for values of a specific ASN.1
type, however other specifications may wish to provide a customized
ABNF [3] description, independent of the ASN.1, as a convenience for
the implementor (equivalent ABNF for the GSER encodings for ASN.1
types commonly occuring in LDAP syntaxes is provided in [14]). Such
a specification SHOULD state that if there is a discrepancy between
the customized ABNF and the GSER encoding defined by this document,
that the GSER encoding takes precedence.
4. Conventions
Throughout this document "type" shall be taken to mean an ASN.1 type,
and "value" shall be taken to mean an ASN.1 value.
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 [1].
5. Generic String Encoding Rules
The GSER encoding of a value of any ASN.1 type is described by the
following ABNF [3]:
Value = BitStringValue /
BooleanValue /
CharacterStringValue /
ChoiceValue /
EmbeddedPDVValue /
EnumeratedValue /
ExternalValue /
GeneralizedTimeValue /
IntegerValue /
InstanceOfValue /
NullValue /
ObjectDescriptorValue /
ObjectIdentifierValue /
Legg Expires 19 February 2002 [Page 3]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
OctetStringValue /
RealValue /
RelativeOIDValue /
SequenceOfValue /
SequenceValue /
SetOfValue /
SetValue /
StringValue /
UTCTimeValue /
VariantEncoding
The ABNF for each of the above rules is given in the following
sections.
5.1 Type Referencing Notations
A value of a type with a defined type name is encoded according to
the type definition on the right hand side of the type assignment for
the type name.
A value of a type denoted by the use of a parameterized type with
actual parameters is encoded according to the parameterized type with
the DummyReferences [12] substituted with the actual parameters.
A value of a tagged or constrained type is encoded as a value of the
type without the tag or constraint, respectively. Tags do not appear
in the string encodings defined by this document. See [8] and [11]
for the details of ASN.1 constraint notation.
A value of an open type denoted by an ObjectClassFieldType (Clause 14
of [10]) is encoded according to the specific type of the value.
A value of a fixed type denoted by an ObjectClassFieldType is encoded
according to that fixed type.
A value of a selection type is encoded according to the type
referenced by the selection type.
A value of a type described by TypeFromObject notation (Clause 15 of
[10]) is encoded according to the denoted type.
A value of a type described by ValueSetFromObjects notation (Clause
15 of [10]) is encoded according to the governing type.
5.2 Restricted Character String Types
Legg Expires 19 February 2002 [Page 4]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
The contents of a string value are encoded as a UTF8 character string
between double quotes, regardless of the ASN.1 string type.
Depending on the ASN.1 string type, and an application's internal
representation of that string type, a translation to or from the UTF8
character encoding may be required. NumericString, PrintableString,
IA5String, VisibleString (ISO646String) are compatible with UTF8 and
do not require any translation. BMPString (UCS-2) and
UniversalString (UCS-4) have a direct mapping to and from UTF8 [6].
For the remaining string types see [8]. Any embedded double quotes
in the resulting UTF8 character string are escaped by repeating the
double quote characters.
A value of the NumericString, PrintableString, TeletexString
(T61String), VideotexString, IA5String, GraphicString, VisibleString
(ISO646String), GeneralString, BMPString, UniversalString or
UTF8String type is encoded according to the <StringValue> rule.
StringValue = dquote *SafeUTF8Character dquote
dquote = %x22 ; " (double quote)
SafeUTF8Character = %x00-21 / %x23-7F / ; ASCII minus dquote
dquote dquote / ; escaped double quote
%xC0-DF %x80-BF / ; 2 byte UTF8 character
%xE0-EF 2(%x80-BF) / ; 3 byte UTF8 character
%xF0-F7 3(%x80-BF) / ; 4 byte UTF8 character
%xF8-FB 4(%x80-BF) / ; 5 byte UTF8 character
%xFC-FD 5(%x80-BF) ; 6 byte UTF8 character
A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor
type is encoded as a string value. GeneralizedTime and UTCTime use
the VisibleString character set so the conversion to UTF8 is trivial.
ObjectDescriptor uses the GraphicString type.
GeneralizedTimeValue = StringValue
UTCTimeValue = StringValue
ObjectDescriptorValue = StringValue
5.3 ChoiceOfStrings Types
It is not uncommon for ASN.1 specifications to define types that are
a CHOICE between two or more alternative ASN.1 string types, where
the particular alternative chosen carries no semantic significance
(DirectoryString [7] being a prime example). Such types are defined
to avoid having to use a complicated character encoding for all
values when most values could use a simpler string type, or to deal
with evolving requirements that compel the use of a broader character
Legg Expires 19 February 2002 [Page 5]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
set while still maintaining backward compatibility.
GSER encodes values of all the ASN.1 string types as UTF8 character
strings so the alternative chosen in a purely syntactic CHOICE of
string types makes no material difference to the final encoding of
the string value.
While there are certain ASN.1 constructs that betray the semantic
significance of the alternatives within a CHOICE type, the absence of
those constructs does not necessarily mean a CHOICE type is purely
syntactic. Therefore, it is necessary for specifications to declare
the purely syntactic CHOICE types so that they may be more compactly
encoded (see Section 5.12). These declared CHOICE types are referred
to as ChoiceOfStrings types.
To be eligible to be declared a ChoiceOfStrings type an ASN.1 type
MUST satisfy the following conditions.
a) The type is a CHOICE type.
b) The component type of each alternative is one of the following
ASN.1 restricted string types: NumericString, PrintableString,
TeletexString (T61String), VideotexString, IA5String,
GraphicString, VisibleString (ISO646String), GeneralString,
BMPString, UniversalString or UTF8String.
c) All the alternatives are of different restricted string types,
i.e. no two alternatives have the same ASN.1 restricted string
type.
d) Either none of the alternatives has a constraint, or all of the
alternatives have exactly the same constraint.
Tagging on the alternative types is ignored.
Consider the ASN.1 parameterized type definition of DirectoryString.
DirectoryString { INTEGER : maxSize } ::= CHOICE {
teletexString TeletexString (SIZE (1..maxSize)),
printableString PrintableString (SIZE (1..maxSize)),
bmpString BMPString (SIZE (1..maxSize)),
universalString UniversalString (SIZE (1..maxSize)),
uTF8String UTF8String (SIZE (1..maxSize)) }
Any use of the DirectoryString parameterized type with an actual
parameter defines a ASN.1 type that satisfies the above conditions.
Recognising that the alternative within a DirectoryString carries no
semantic significance, this document declares (each and every use of)
Legg Expires 19 February 2002 [Page 6]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
DirectoryString{} to be a ChoiceOfStrings type.
Other specifications MAY declare other types satisfying the above
conditions to be ChoiceOfStrings types. The declaration SHOULD be
made at the point where the ASN.1 type is defined, otherwise it
SHOULD be made at the point where it is introduced as, or in, an LDAP
attribute or assertion syntax.
5.4 Identifiers
An <identifier> conforms to the definition of an identifier in ASN.1
notation (Clause 11.3 of [8]). It begins with a lowercase letter and
is followed by zero or more letters, digits, and hyphens. A hyphen
is not permitted to be the last character and a hyphen is not
permitted to be followed by another hyphen. The case of letters in
an identifier is always significant.
identifier = lowercase *alphanumeric *(hyphen 1*alphanumeric)
alphanumeric = uppercase / lowercase / decimal-digit
uppercase = %x41-5A ; "A" to "Z"
lowercase = %x61-7A ; "a" to "z"
decimal-digit = %x30-39 ; "0" to "9"
hyphen = "-"
5.5 BIT STRING
A value of the BIT STRING type is encoded according to the
<BitStringValue> rule. If the definition of the BIT STRING type
includes a named bit list, the <bit-list> form of <BitStringValue>
rule MAY be used. If the number of bits in a BIT STRING value is a
multiple of four the <hstring> form of <BitStringValue> MAY be used.
The <bstring> form of <BitStringValue> is used otherwise.
BitStringValue = bstring / hstring / bit-list
The <bit-list> rule encodes the one bits in the bit string value as a
comma separated list of identifiers. Each <identifier> MUST be one
of those in the named bit list. An <identifier> MUST NOT appear more
than once in the same <bit-list>. The <bstring> rule encodes each
bit as the character "0" or "1" in order from the first bit to the
last bit. The <hstring> rule encodes each group of four bits as a
hexadecimal number where the first bit is the most significant. An
odd number of hexadecimal digits is permitted.
bit-list = "{" [ sp identifier
*( "," sp identifier ) ] sp "}"
Legg Expires 19 February 2002 [Page 7]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
hstring = squote *hexadecimal-digit squote %x48 ; '...'H
hexadecimal-digit = %x30-39 / ; "0" to "9"
%x41-46 ; "A" to "F"
bstring = squote *binary-digit squote %x42 ; '...'B
binary-digit = "0" / "1"
sp = *%x20 ; zero, one or more space characters
squote = %x27 ; ' (single quote)
5.6 BOOLEAN
A value of the BOOLEAN type is encoded according to the
<BooleanValue> rule.
BooleanValue = %x54.52.55.45 / ; "TRUE"
%x46.41.4C.53.45 ; "FALSE"
5.7 ENUMERATED
A value of the ENUMERATED type is encoded according to the
<EnumeratedValue> rule. The <identifier> MUST be one of those in the
list of enumerations in the definition of the ENUMERATED type.
EnumeratedValue = identifier
5.8 INTEGER
A value of the INTEGER type is encoded according to the
<IntegerValue> rule. If the definition of the INTEGER type includes
a named number list, the <identifier> form of <IntegerValue> MAY be
used, in which case the <identifier> MUST be one of those in the
named number list.
IntegerValue = "0" /
positive-number /
("-" positive-number) /
identifier
positive-number = non-zero-digit *decimal-digit
non-zero-digit = %x31-39 ; "1" to "9"
5.9 NULL
Legg Expires 19 February 2002 [Page 8]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
A value of the NULL type is encoded according to the <NullValue>
rule.
NullValue = %x4E.55.4C.4C ; "NULL"
5.10 OBJECT IDENTIFIER and RELATIVE-OID
A value of the OBJECT IDENTIFIER type is encoded according to the
<ObjectIdentifierValue> rule. The <ObjectIdentifierValue> rule
allows either a dotted decimal representation of the OBJECT
IDENTIFIER value or an object descriptor name, i.e. <descr>. The
<descr> rule is described in [4]. An object descriptor name is
potentially ambiguous and should be used with care.
ObjectIdentifierValue = numeric-oid / descr
numeric-oid = oid-component 1*( "." oid-component )
oid-component = "0" / positive-number
A value of the RELATIVE-OID [9] type is encoded according to the
<RelativeOIDValue> rule.
RelativeOIDValue = oid-component *( "." oid-component )
5.11 OCTET STRING
A value of the OCTET STRING type is encoded according to the
<OctetStringValue> rule. The octets are encoded in order from the
first octet to the last octet. Each octet is encoded as a pair of
hexadecimal digits where the first digit corresponds to the four most
significant bits of the octet. If the hexadecimal string does not
have an even number of digits the four least significant bits in the
last octet are assumed to be zero.
OctetStringValue = hstring
5.12 CHOICE
A value of a CHOICE type is encoded according to the <ChoiceValue>
rule. The <ChoiceOfStringsValue> encoding MAY be used if the
corresponding CHOICE type has been declared a ChoiceOfStrings type.
This document declares DirectoryString to be a ChoiceOfStrings type
(see Section 5.3). The <IdentifiedChoiceValue> form of <ChoiceValue>
is used otherwise.
ChoiceValue = IdentifiedChoiceValue /
Legg Expires 19 February 2002 [Page 9]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
ChoiceOfStringsValue
IdentifiedChoiceValue = identifier ":" Value
ChoiceOfStringsValue = StringValue
For implementations that recognise the internal structure of the
DirectoryString CHOICE type (e.g. X.500 directories [15]), if the
character string between the quotes in a <StringValue> contains only
characters that are permitted in a PrintableString the
DirectoryString is assumed to use the printableString alternative,
otherwise it is assumed to use the uTF8String alternative. The
<IdentifiedChoiceValue> rule MAY be used for a value of type
DirectoryString to indicate a different alternative to the one that
would otherwise be assumed from the string contents. No matter what
alternative is chosen, the <Value> will still be a UTF8 encoded
character string, however it is a syntax error if the characters in
the UTF8 string cannot be represented in the string type of the
chosen alternative.
Implementations that don't care about the internal structure of a
DirectoryString value MUST be able to parse the
<IdentifiedChoiceValue> form for a DirectoryString value, though the
particular identifier found will be of no interest.
5.13 SEQUENCE and SET
A value of a SEQUENCE type is encoded according to the
<SequenceValue> rule. The <ComponentList> rule encodes a comma
separated list of the particular component values present in the
SEQUENCE value, where each component value is preceded by the
corresponding identifier from the SEQUENCE type definition. The
components are encoded in the order of their definition in the
SEQUENCE type.
SequenceValue = ComponentList
ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
NamedValue = identifier msp Value
msp = 1*%x20 ; one or more space characters
A value of a SET type is encoded according to the <SetValue> rule.
The components are encoded in the order of their definition in
the SET type (i.e. just like a SEQUENCE value).
This is a deliberate departure from ASN.1 value notation where
the components of a SET can be written in any order.
SetValue = ComponentList
Legg Expires 19 February 2002 [Page 10]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
SEQUENCE and SET type definitions are sometimes extended by the
inclusion of additional component types, so an implementation SHOULD
be capable of skipping over any <NamedValue> encoding with an
identifier that is not recognised, on the assumption that the sender
is using a more recent definition of the SEQUENCE or SET type.
5.14 SEQUENCE OF and SET OF
A value of a SEQUENCE OF type is encoded according to the
<SequenceOfValue> rule, as a comma separated list of the instances in
the value. Each instance is encoded according to the component type
of the SEQUENCE OF type.
SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
A value of a SET OF type is encoded according to the <SetOfValue>
rule, as a list of the instances in the value. Each instance is
encoded according to the component type of the SET OF type.
SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
5.15 CHARACTER STRING
A value of the unrestricted CHARACTER STRING type is encoded
according to the corresponding SEQUENCE type defined in Clause 39.5
of [8] (see [14] for equivalent ABNF).
CharacterStringValue = SequenceValue
5.16 EMBEDDED PDV
A value of the EMBEDDED PDV type is encoded according to the
corresponding SEQUENCE type defined in Clause 32.5 of [8] (see [14]
for equivalent ABNF).
EmbeddedPDVValue = SequenceValue
5.17 EXTERNAL
A value of the EXTERNAL type is encoded according to the
corresponding SEQUENCE type defined in Clause 33.5 of [8] (see [14]
for equivalent ABNF).
ExternalValue = SequenceValue
Legg Expires 19 February 2002 [Page 11]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
5.18 INSTANCE OF
A value of the INSTANCE OF type is encoded according to the
corresponding SEQUENCE type defined in Annex C of [10].
InstanceOfValue = SequenceValue
5.19 REAL
A value of the REAL type MUST be encoded as "0" if it is zero,
otherwise it is encoded as either the special value <PLUS-INFINITY>,
the special value <MINUS-INFINITY>, an optionally signed <realnumber>
(based on the extended value notation for REAL from [16]) or as a
value of the corresponding SEQUENCE type for REAL defined in Clause
20.5 of [8] (see [14] for equivalent ABNF).
RealValue = "0" ; zero REAL value
/ PLUS-INFINITY ; positive infinity
/ MINUS-INFINITY ; negative infinity
/ realnumber ; positive base 10 REAL value
/ "-" realnumber ; negative base 10 REAL value
/ SequenceValue ; non-zero REAL value, base 2 or 10
realnumber = mantissa exponent
mantissa = (positive-number [ "." *decimal-digit ])
/ ( "0." *("0") positive-number )
exponent = "E" ( "0" / ([ "-" ] positive-number))
PLUS-INFINITY = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
; "PLUS-INFINITY"
MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
; "MINUS-INFINITY"
5.20 Variant Encodings
The values of some named complex ASN.1 types have special string
encodings. These special encodings are always used instead of the
encoding that would otherwise apply based on the ASN.1 type
definition.
VariantEncoding = RDNSequenceValue /
RelativeDistinguishedNameValue /
ORAddressValue
A value of the RDNSequence type, i.e. a distinguished name, is
encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN
character string. The character string is first derived according to
Legg Expires 19 February 2002 [Page 12]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
the <distinguishedName> rule in Section 3 of [5], and then it is
encoded as if it were a UTF8String value, i.e. between double quotes
with any embedded double quotes escaped by being repeated.
RDNSequenceValue = StringValue
A RelativeDistinguishedName value that is not part of an RDNSequence
value is encoded according to the <RelativeDistinguishedNameValue>
rule as a quoted character string. The character string is first
derived according to the <name-component> rule in Section 3 of [5],
and then it is encoded as if it were a UTF8String value.
RelativeDistinguishedNameValue = StringValue
A value of the ORAddress type is encoded according to the
<ORAddressValue> rule as a quoted character string. The character
string is first derived according to the textual representation of
MTS.ORAddress from [2], and then it is encoded as if it were an
IA5String value.
ORAddressValue = StringValue
6. GSER Transfer Syntax
The following OBJECT IDENTIFIER has been assigned to identify the
Generic String Encoding Rules:
{ 1 2 36 79672281 0 0 }
This OBJECT IDENTIFIER would be used, for example, to describe the
transfer syntax for a GSER encoded data-value in an EXTERNAL or
EMBEDDED PDV value.
7. Security Considerations
The Generic String Encoding Rules do not necessarily enable the exact
octet encoding of values of the TeletexString, VideotexString,
GraphicString or GeneralString types to be reconstructed, so a
transformation from DER to GSER and back to DER may not reproduce the
original DER encoding. This has consequences for the verification of
digital signatures.
8. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Legg Expires 19 February 2002 [Page 13]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
Levels", BCP 14, RFC 2119, March 1997.
[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Information Technology - Open Systems Interconnection - The
Directory: Selected attribute types
[8] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
Information Technology - Abstract Syntax Notation One (ASN.1):
Specification of basic notation
[9] ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
8824-1:1998/Amd 1:2000 Relative object identifiers
[10] ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
Information Technology - Abstract Syntax Notation One (ASN.1):
Information object specification
[11] ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
Information Technology - Abstract Syntax Notation One (ASN.1):
Constraint specification
[12] ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
Information Technology - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 specifications
9. Informative References
[13] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
Legg Expires 19 February 2002 [Page 14]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
[14] Legg, S., "Common Elements of GSER Encodings",
draft-legg-ldap-gser-abnf-xx.txt, a work in progress, August
2002.
[15] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - The
Directory: Overview of concepts, models and services
[16] ITU-T Recommendation X.680 - Corrigendum 3 (02/2001)
[17] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998
Information Technology - ASN.1 encoding rules: Specification of
Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)
10. Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. Author's Address
Steven Legg
Legg Expires 19 February 2002 [Page 15]
INTERNET-DRAFT Generic String Encoding Rules August 19, 2002
Adacel Technologies Ltd.
405-409 Ferntree Gully Road
Mount Waverley, Victoria 3149
AUSTRALIA
Phone: +61 3 9451 2107
Fax: +61 3 9541 2121
EMail: steven.legg@adacel.com.au
Legg Expires 19 February 2002 [Page 16]

2299
doc/drafts/draft-legg-ldapext-component-matching-xx.txt Normal file
View file

File diff suppressed because it is too large Load diff

0
doc/drafts/draft-zeilenga-ldap-t-f-02.txt → doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
View file