[caops-wg] Subtree specifications

[David Chadwick]

Here is the definition of X.500 subtrees from X.501 section 12.3. This 
is a general mechanism for specifying any sort of DN namespace which 
might be of use to you for specifying your signing policies.

If you want a layman's explanation of this mechanism there is a section 
in my book (2.12.1 The Subtree Specification Attribute) which can be 
found at

http://sec.cs.kent.ac.uk/x500book/Chapter.2/Chapter2.htm#2.9%20THE%20DIRECTORY

There are also a few examples at

http://sec.cs.kent.ac.uk/x500book/Chapter.2/fig2-9.gif

from which you can see how the c=ch, o=cern problem could easily be 
dealt with using subtree specification.

As a footnote, subtree specifications were originally in X.509 name 
constraints, but were replaced in 1996 by GeneralSubtrees just before 
the standard was released, without people fully appreciating what had 
been done.


12.3	Subtrees
12.3.1	Overview
A subtree is a collection of object and alias entries situated at the 
vertices of a tree. Subtrees do not contain subentries. The prefix 
"sub", in subtree, emphasizes that the base (or root) vertex of this 
tree is usually subordinate to the root of the DIT.
A subtree begins at some vertex and extends to some identifiable lower 
boundary, possibly extending to leaves. A subtree is always defined 
within a context which implicitly bounds the subtree. For example, the 
vertex and lower boundaries of a subtree defining a replicated area are 
bounded by a naming context. Similarly, the scope of a subtree defining 
a specific administrative area is limited to the context of an enclosing 
autonomous administrative area.
12.3.2	Subtree specification
Subtree specification is the definition of a subset of the entries below 
a specified vertex which forms the base of the subtree or subtree 
refinement.
The vertex and/or the lower boundary of the subtree may be implicitly 
specified, in which case they are determined by the context within which 
the subtree is used.
The vertex and/or the lower boundary may be explicitly specified using 
the mechanism specified in this clause. This mechanism may also be used 
to specify subtree refinements which are not true tree structures.
NOTE – The topological concept of a (sub)tree is useful in considering 
such specifications, although a particular specification may determine a 
collection of entries that are not located at the vertices of a single 
(sub)tree. The term subtree refinement is preferred when the entries of 
the collection are not so located.
Specification of a subtree consists of three optional elements of 
specification which identify the base of the subtree, and then reduce 
the collection of subordinate entries. These elements of specification are:
a)	Base – The root vertex of the subtree or subtree refinement produced 
by the evaluation of a subtree specification;
b)	Chop – A set of assertions concerning the names of the subordinate 
entries; and
c)	Specification filter – A proper subset of the assertive capability of 
a filter applied to the subordinates.
The specification of a subtree or subtree refinement may be represented 
by the following ASN.1 type:

SubtreeSpecification  ::=  SEQUENCE {
	base   			[0]	LocalName DEFAULT { },
						COMPONENTS OF  ChopSpecification,
	specificationFilter	[4]	Refinement OPTIONAL }
	-- empty sequence specifies whole administrative area

The three components of this sequence correspond to the three 
specification elements identified above.
Where a value of SubtreeSpecification identifies a collection of entries 
that are located at the vertices of a single subtree, the collection is 
termed a subtree, otherwise the collection is termed a subtree refinement.
The SubtreeSpecification type provides a general purpose mechanism for 
the specification of subtrees and subtree refinements. Any particular 
use of this mechanism defines the specific semantics of precisely what 
is specified and may impose limitations or constraints on the components 
of SubtreeSpecification.
When each of the components of SubtreeSpecification is absent (i.e. a 
value of type SubtreeSpecification which is an empty sequence, {}), the 
subtree so specified is implicitly determined by the context within 
which the SubtreeSpecification is used.
These terms are illustrated in Figure 9, for the case where subtrees are 
deployed within the context of administrative areas.
12.3.3	Base
The base component of SubtreeSpecification represents the root vertex of 
the subtree or subtree refinement. This may be an entry which is 
subordinate to the root vertex of the identified scope or may be the 
root vertex of the identified scope itself (the default).


Figure 9 – Specification of Subtrees and Subtree Refinements
within the context of Administrative Areas
The relative name of the root vertex of the subtree with respect to the 
root vertex of the identified scope is a value of typeLocalName:

LocalName  ::=  RDNSequence

Note that the root vertex of the identified scope and the root vertex of 
the subtree coincide when LocalName is omitted from SubtreeSpecification.
RDNs used to name the root vertex of the subtree shall be primary RDNs.
12.3.4	Chop Specification
The ChopSpecification component consists of a set of assertions 
concerning the names of the subordinates of a base. It consists of a 
value of type ChopSpecification:

ChopSpecification  ::=  SEQUENCE  {
	specificExclusions	[1]	SET SIZE (1..MAX) OF CHOICE {
		chopBefore  		[0]	LocalName,
		chopAfter			[1]	LocalName } OPTIONAL,
	minimum			[2]	BaseDistance DEFAULT 0,
	maximum			[3]	BaseDistance OPTIONAL }


This type is intended to permit the specification of a tree structure 
(or subset thereof) starting at the base by two methods, specific 
exclusions and base distance.
Where any attribute in an RDN in chopBefore or chopAfter has multiple 
distinguished values differentiated by context, the primary 
distinguished value shall be used as the value in the RDN in LocalName.
12.3.4.1	Specific Exclusions
The specificExclusions component has two forms, chopBefore and 
chopAfter, which may be used individually or in combination.
The chopBefore component defines a list of exclusions, each in terms of 
some limit point which is to be excluded, along with its subordinates, 
from the subtree or subtree refinement. The limit points are the entries 
identified by a LocalName, relative to the base.
The chopAfter component defines a list of exclusions, each in terms of 
some limit point whose subordinates are to be excluded from the subtree 
or subtree refinement. The limit points are the entries identified by a 
LocalName, relative to the base.
12.3.4.2	Minimum and Maximum
These components allow exclusion of all entries that are superior to 
entries that are minimum RDN arcs below the base as well as entries 
which are subordinate to entries that are maximum RDN arcs below the 
base. These distances are expressed by values of the type BaseDistance:

BaseDistance  ::=  INTEGER (0..MAX)

For the purpose of chop specifications, a compound entry is counted as a 
single entry. In a compound entry, all family members are counted as 
having the same base distance as the ancestor, since they are all part 
of the same logical entry.
A value of minimum equal to zero (the default), corresponds to the base. 
An absent maximum component indicates that no lower limit should be 
imposed on the subtree or subtree refinement.
12.3.5	Specification Filter
The specificationFilter component consists of a proper subset of the 
assertive capability of a filter (see ITU-T Rec. X.511 | ISO/IEC 9594-3) 
applied to the subordinates of a base. Only entries for which the filter 
evaluates to true are included in the resulting subtree refinement. It 
consists of a value of type Refinement:

Refinement  ::=  CHOICE {
	item		[0]	OBJECT-CLASS.&id,
	and		[1]	SET OF Refinement,
	or		[2]	SET OF Refinement,
	not		[3]	Refinement }

A Refinement evaluates to TRUE as if it were a filter making an equality 
assertion regarding values of the attribute type objectClass only.
If a family member is excluded from a subtree by this specification, all 
its subordinate family members are also excluded.

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Skype Name: davidwchadwick
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: D.W.Chadwick at kent.ac.uk
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://www.cs.kent.ac.uk/research/groups/iss/index.html
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************