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%20DIRECTO... 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@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 *****************************************************************