GFD-I.

189 David Groep, Nikhef

Jens Jensen, STFC
CAOPS-WG
June 6 2011

Relying Party Defined Namespace Constraints Policies in a Policy Bridge PKI Environment

Status of This Document

This document provides information to the Grid community. It does not define any standards or
technical recommendations. Distribution is unlimited.

Copyright Notice
Copyright © Open Grid Forum (2006-2011). All Rights Reserved.

Abstract
Relying Party Defined Namespace Constraints (RPDNC) are limitations on the subject
namespace issued by X.509 certification authorities (CAs) that are defined and enforced by the
end-point at the relying party side. As grid authentication based on X.509 credentials provides the
subject DN as a handle that identifies the authenticated entity, the capability to ensure subject
name uniqueness is of critical importance in ensuring overall integrity of the authentication
system.
This document described the rationale and use cases for relying party defined name space
constraints, and lists the set of desired features a policy language expressing such constraints
should have.
GFD-I.189 June 6, 2011

Contents

Abstract ........................................................................................................................................... 1  
1.   Introduction .............................................................................................................................. 3  
2.   Rationale for Relying Party Defined Namespace Constraints (RPDNC) ................................. 3  
3.   Namespaces ............................................................................................................................ 4  
4.   RPDNC Policy Language and Expression Requirements........................................................ 5  
4.1   Co-existence of authorities with and without RPDNC policies.......................................... 5  
4.2   Independence of RPDNC policies .................................................................................... 5  
a. Granularity of association of RPDNC with CAs.................................................................... 5  
b. Distribution and verification of RPDNC ................................................................................ 5  
c. Validation of certificates against RPDNC ............................................................................. 5  
d. Combination ......................................................................................................................... 5  
4.3   Support for dynamic hierarchies ....................................................................................... 5  
4.4   Support for static hierarchies ............................................................................................ 5  
4.5   Expression of subject DN namespaces as strings ............................................................ 5  
4.6   Usability and human readability of the policy.................................................................... 6  
4.7   Name sub-tree support and the use of wild cards in names............................................. 6  
4.8   Sub-tree specific policies and policy-file precedence ....................................................... 6  
4.9   Independence of non-namespace trust anchor characteristics ........................................ 6  
4.10   Policy collision ............................................................................................................... 6  
4.11   Policy combination ........................................................................................................ 6  
5.   RPDNC distribution and life cycle ............................................................................................ 6  
6.   Current RPDNC Policy Languages .......................................................................................... 7  
7.   Examples ................................................................................................................................. 7  
7.1 Simple hierarchy ............................................................................................................... 7  
7.2   Namespace slicing ............................................................................................................ 7  
7.3   Multi-tier hierarchy ............................................................................................................ 8  
7.4   Multi-tier issuing hierarchy ................................................................................................ 8  
7.5   Policy Root........................................................................................................................ 8  
7.6   Improving Grid security through namespaces .................................................................. 9  
7.7   Distinguishing types of clients........................................................................................... 9  
7.8   Combining and the unknown ............................................................................................ 9  
8   Security Considerations ......................................................................................................... 10  
9   Contributors............................................................................................................................ 10  
Intellectual Property Statement ..................................................................................................... 10  
Disclaimer...................................................................................................................................... 10  
Full Copyright Notice ..................................................................................................................... 10  
References .................................................................................................................................... 11  
Appendix A .................................................................................................................................... 12  
A.1   Dynamic Policy Extension............................................................................................... 12  

caops-wg@ogf.org 2
GFD-I.189 June 6, 2011

1. Introduction

This document described the rationale and use cases for relying party defined name space
constraints in X.509 Certificate Authorities, and lists the set of desired features a policy language
expressing such constraints should have.

The background to this document can be found in the Trust Anchor Management group current
requirements document, the most recent being https://datatracker.ietf.org/doc/draft-ietf-pkix-ta-
mgmt-reqs/ [visited June 2010]:
A trust anchor represents an authoritative entity via a public key and associated data.
The public key is used to verify digital signatures and the associated data is used to
constrain the types of information for which the trust anchor is authoritative. A relying
party uses trust anchors to determine if a digitally signed object is valid by verifying a
digital signature using the trust anchor's public key, and by enforcing the constraints
expressed in the associated data for the trust anchor.

This document describes the requirements for this “associated data” for managing subject
namespaces for Grid PKIs.
2. Rationale for Relying Party Defined Namespace Constraints (RPDNC)

Relying Party Defined Namespace Constraints (RPDNC) are limitations on the subject
namespace in which X.509 certificate authorities (CAs) issue certificates. These constraints are in
principle defined by the Relying Party (RP) and enforced by the end-point at the relying party
side. In grid authentication based on X.509 credentials, the subject distinguished name (DN)
1
provides a handle that identifies the authenticated entity . The capability to ensure subject name
uniqueness is thus of critical importance in ensuring overall integrity of the authentication system.
To some extent, RPDNC help enforce this constraint. Moreover, in certain types of security
incidents, RPDNC help limit the scope of the incident. Finally, RPDNC give the RP some
additional control over the range of certificates they accept.

In practice, the RPDNC are often provided by the IGTF [IGTF] as part of a trust anchor
distribution, usually provided by the CA upon IGTF accreditation, or by a coordinated-deployment
project, but can be defined, replaced or augmented by individual relying parties. In principle, RPs
ultimately decide which CAs and which certificates issued by those CAs to trust, but the RPNDC
is normally used to enable the following use cases:

• Enforce non-overlapping CA name spaces. RPDNC allow relying parties to ensure that
within the ensemble of PKIs they trust there can be no overlaps in the subject names
issued by the diverse CAs, whether inadvertent or intentional.
• Allow CAs to sub-divide their subject name space and apply different policies to different
branches of this namespace in absence of any other mechanisms. For example, a
specific part of the namespace may be reserved for end-entity certificates or subordinate
CA certificates that comply with specific additional requirements requested by relying
parties, and these relying parties can opt to accept only the part of the namespace where
2
such requests are honoured .

1
There are multiple handles that identify the authenticated entity, but the subject
distinguished name is used most frequently as the primary handle, since it is persistent and
uniquely assigned to the entity. This handle can then be used directly, but is also frequently used
in an indirect manner when obtaining other attributes that are associated to this ‘handle’ of the
authenticated entity. For example, an attribute issuance service such as VOMS relies on the
subject distinguished name to provide attributes associated with the authenticated entity.
2
For example, in absence of an RPDNC mechanism, a root CA can issue any number of
subordinate CAs, and credentials issued by these subordinates in the absence of other methods

caops-wg@ogf.org 3
GFD-I.189 June 6, 2011

Authority-defined namespace constraints policies are common in PKI Bridging architectures that
use a Bridge Certification Authority [RFC4158] to express trust relationships between the
participating authorities. In a policy bridge architecture, this technical means of expressing
relationships and coordinating the namespace for the subject directory names does not exist.
With a policy bridge, it is up to the relying parties to enforce limitations on the subject namespace
of each of the participating authorities in order to guarantee subject name uniqueness across the
PKI as seen from that specific relying party.

3. Namespaces
For the purposes of this document, a Namespace is a non-empty set of Distinguished Names
(DNs) as used in RFC 5280, containing the subject Distinguished Names that are or can be
issued by a single CA (as constrained by its policies). With each full DN being an ordered
3
sequence of sets of attribute-value pairs (referred to as relative distinguished names, RDNs ), the
set of distinguished names will have a fixed (common) part and a naming (variable) part. The
4
fixed, ‘common’ part that the longest initial sequence of RDNs that all DNs have in common. The
naming, ‘variable’ part consists of all remaining RDNs.

For example, the two DNs that, in RFC2253 format, are expressed as:

CN=John Doe, OU=pdp, O=rl, DC=example, DC=org

CN=John Doe, O=nikhef, DC=example, DC=org

have a fixed part: the common initial set of RDNs (namely DC=org and DC=example), and a
remaining naming part: the ‘variable’ part of the DN (the O, OU and CN RDNs)

The two DNs

CN=John Doe, O=rl, DC=example, DC=org

CN=John Doe, O=rl, DC=example, DC=com

have an empty (null) fixed part, since the first RDN in the sequence is different.

The Namespace of a CA is defined as the set of all DNs that the CA can issue by its policy. For
convenience, the Namespace is often summarised by quoting just the fixed part (which is by
definition the same for all subject DNs). This simplification allows the variable part to contain any
sequence of any RDNs, subject only to technical restrictions such as the total length of the DN.

We define a Relying Party Defined Namespace Constraint (RPDNC) as a set of restrictions

enforced by the relying party (as opposed to, e.g., nameConstraints set by a certification
authority) that defines the set of fixed parts that are accepted, rejected, or for which no explicit
decision is made by the Relying Party. The RPDNC set may be different from the Namespace of
the CA.

Again occasionally for simplicity reasons, we may liken the RPDNC to the positive set, the

of enforcement would automatically be trusted since the root is part of the trust anchor repository.
See example 6.5.
3
An RDN is defined as a SET of AttributeTypeAndValue [RFC5280] but we require these
sets to contain exactly one element; thus the type and value are both well defined.
4
“Initial sequence” means a (possibly empty) subsequence starting with the first RDN of the
ASN.1 encoding of the DN (RDNSequence in RFC5280), irrespective of how this is represented
as a string. For example, in the LDAP representation (e.g. RFC2253 section 2.1), “DC=org”,
“DC=example,DC=org” and “DC=host,DC=example,DC=org” are all initial sequences of the
DN “DC=host,DC=example,DC=org”.

caops-wg@ogf.org 4
GFD-I.189 June 6, 2011

Namespace for which the policy accepts DNs can be called the RPDNC. In turn, this can be
summarised by its fixed part for further simplification.
Finally, we shall refer to the engine which accepts a DN and parses it against a policy and returns
a decision as a Policy Decision Point (PDP).

4. RPDNC Policy Language and Expression Requirements

A quick-scan in the community of Relying Parties, e-Science grid deployment projects and Grid
Certification Authorities suggested the following requirements for expressing a Relying Party
Defined Namespace Constraints Policy. To some extent, priorities are indicated by “must”
(essential to implement security, or to ensure basic or robust operations), “should” (helps meet
important use cases), and “may” (supporting slightly more exotic use cases, or the lack of this
feature can be worked around.)

4.1 Co-existence of authorities with and without RPDNC policies

It must be possible to have issuers with and without namespace constraints policies co-exist
within the same trust anchor repository.

4.2 Independence of RPDNC policies

a. Granularity of association of RPDNC with CAs

5
It must be possible to associate a RPDNC with each individual trust anchor .
b. Distribution and verification of RPDNC
It must be possible to distribute and verify (cf. Requirement 4.6) RPDNC policies in conjunction
with each individual trust anchor, independent of any other trust anchors present in the trust
anchor repository. “Verification” here means verification by a human, checking that the policy
does what is expected of it.
c. Validation of certificates against RPDNC
For a given trust anchor with an RPDNC associated to it, the evaluation of any subject certificate
under this trust anchor against the RPDNC must be independent of the RPDNCs of trust anchors
that are not in the trust path.
d. Combination
There are use cases where it is useful to associate multiple RPDNC to a single trust anchor (see
Example 6.8). See also requirement 4.11.

4.3 Support for dynamic hierarchies

It may be possible to support the concept of “subordinate” issuers in a hierarchical chain of
issuers, such that a single RPDNC supports the expression of namespace constraints on any
subordinate issuer.

4.4 Support for static hierarchies

It must be possible to exhaustively list namespaces. A RPDNC may limit the number of DNs that
can appear in such an explicit list, but in this case the upper limit should not be less than 32 per
installed trust anchor.

4.5 Expression of subject DN namespaces as strings

The string rendering identifier naming of directoryNames and X.500 DNs in the policy expression
6
must comply with RFC4514 .

5
A single CA may operate with more than one trust anchor, e.g., by signing end-entity
(EE) certificates with more than one CA certificate (with distinct names), or by having a separate
certificate to sign CRLs.
6
For purposes of the RPDNC, the string representation of the DN must follow RFC 4514, where
additionally the shortest possible string form of the attribute name as listed in the there-listed

caops-wg@ogf.org 5
GFD-I.189 June 6, 2011

4.6 Usability and human readability of the policy

The format used to express RPDNC policies must be human readable in order for relying parties
to visibly inspect, edit, and assess the namespace constraint policy.

4.7 Name sub-tree support and the use of wild cards in names
7
The policy expression must support pattern matching with at least a match-all wildcard. The
wildcard should work on the full string representation of the DN. It must be possible to match the
variable part RDNs in a namespace with a wildcard. It should be possible to exclude branches of
the matching.

4.8 Sub-tree specific policies and policy-file precedence

It must be possible to explicitly set a namespace constraints policy for a subordinate issuer,
without modifying the policy collection (file) for the up-stream issuer(s). Such a policy on a
subordinate issuer must not be able to broaden the namespace constraints defined by higher-
level CAs.

4.9 Independence of non-namespace trust anchor characteristics

A subordinate authority trust anchor must be able to change (i.e. a subordinate could be
compromised and re-keyed) without having to change the namespace constraints policy in any
end-system configuration, provided it does not change its DN.

4.10 Policy collision

The probability for collisions in the policy expression format must be vanishingly small.

4.11 Policy combination

It should be possible to selectively override parts of a name space definition received by agents
of the relying party by ‘downstream’ redistributors or RPs, without modifying distributed RPDNC
files.

Some of the desired features correspond to similar namespace constraints requirements in the
X.509. It is advised for a RPDNC policy language to follow closely the X.509 namespace
constraints where possible.

5. RPDNC distribution and life cycle

The RPDNC is associated with a trust anchor or set of trust anchors, and should be managed
together with the trust anchor. If a trust anchor distribution is used that provides RPDNCs
alongside the trust anchor, and if those RPDNCs are not modified by the individual relying party,
they should be installed and decommissioned together with the trust anchors involved.

If an RPDNC is modified locally, or – in a chain of trust anchors – an RPDNC of a higher-level

trust anchor has been modified locally, any changes in the trust anchor chain at the same or a
subordinate level should be updated to reflect the intended policy of the relying party.

RPDNC definitions for trust anchors that are not present in the trust anchor store are not
evaluated, but should be removed in order to prevent accidental use in case the associated trust
anchor is installed at a later date.

Registry must be used, and the attribute 1.2.840.113549.1.9.1 must be stringified as

“emailAddress”. Where a normative GFD defining the string representation of an attribute name
exists, this document will be authoritative.An RDN must not contain more than one attribute.
7
Although it was requested to support wildcard matching anywhere in the pattern, in order
to accommodate distinguished names where the most-variable part of the DN was not at the end
of the string. However, this request conflicts with the request to align closely with the SubTree
namespace constraints as defined in X.500

caops-wg@ogf.org 6
GFD-I.189 June 6, 2011

6. Current RPDNC Policy Languages

The first RPDNC Policy language was introduced in the Globus Toolkit [GT] in 1997, based on
the EACL Extended ACL language format [EACL]. In this policy, commonly referred to as the
“signing policy”, specific restrictions can be based on the subject namespace on a per-authority
basis. For all Globus Toolkit releases version 2.0 and higher, this policy is stored in a single file
associated with each CA certificate. The implementation allows for a list of allowed namespaces
to be expressed, within certain limitations.

An alternative “namespaces” policy language [NS96] has been experimentally distributed since
2005 as part of the Common Trust Anchor distribution of the International Grid Trust Federation.

7. Examples

This section describes examples, most of which are taken directly from real-life cases. For
convenience, the examples do not distinguish between a CA and its CA certificate unless stated
otherwise.
The lines in the graphs indicate a directed signing relationship (from the top downwards, the
higher level CA signs the subordinate CAs) and a bidirectional ‘has common management’
relationship.

7.1 Simple hierarchy

Root

CA1 CA2 CA3

[Requirements 4.2, 4.4, 4.8]

This example shows a simple hierarchy. We assume CA1 issues Grid EE certificates. In this
case, the RPDNC are defined to permit all end entities issued by CA1, and obviously none from
CA2 and CA3. In Globus-based Grids, the Root will also have to be installed. For the Root, the
8
RPDNC is then defined to accept CA1 only and not CA2 or CA3 .

7.2 Namespace slicing

[Requirements 4.5, 4.6, 4.7]

A CA issues EE certificates: ..., OU=Koalas, O=Grid, C=XX and ..., OU=Wombats, O=Grid,
C=XX.
However, this CA is not trusted on the Grid to authenticate Wombats. The Relying Party (RP) will
9 10
wish to implement an RPDNC which enables Koalas to access the Grid and not Wombats , .

8
In some versions of the Globus Toolkit (specifically versions 1.0 – 1.1.4, as well as version
4.0.8), the signing policy RPDNC must permit the Root to sign itself.
9
Some CAs do not permit slicing their namespaces like this. In this example, if the OU is not
validated by the RA, or no special meaning is associated with the OU, it makes sense that the CA
shall not permit RPs to distinguish EEs by OU.
10
One might argue this should be done by the CA giving different policy OIDs to Koalas and
Wombats, and RPs should be able to check this. Support for this in middleware is beginning to
appear as of this writing but is not ubiquitous. Also, there are many cases where CAs have
different classes of certificates (e.g., personal/host/robot) in different namespaces but give the
same OIDs to all certificates because they are signed under the same policy.

caops-wg@ogf.org 7
GFD-I.189 June 6, 2011

7.3 Multi-tier hierarchy

Root

CA1 CA2

CA1-1 CA1-2

[Requirements 4.2, 4.4]

In this example, only CA1-1 issues EE certificates which are trusted on the Grid. In traditional
Globus-based Grids, this means the path CA1-1  CA1  Root is installed on the server.
There are two use cases: one is to manage the namespaces for secured Grid resources which
require each certificate in the path to be installed, and the other is to manage the namespace for
those that do not. For the latter, the problem is the client may send CA1-2 and CA1 or CA2 along
with its EE certificate (if issued by CA1-2, resp., CA2), and these certificates will be accepted
because the server uses the supplied intermediate certificates to build a valid chain to the Root.
In this case, RPDNC for CA1 shall ensure that only CA1-1 can be used, and likewise, RPDNC for
the Root shall ensure that only CA1 will be relied on to build validation chains.
In the absence of RPDNC, the traditional approach to the trust repository is to install only the
trusted CA, CA1-1 in this example. However, we still need to build a validation chain to the Root
because we require that the CRLs of CA1 and the Root be checked during the validation of an EE
certificate issued by CA1-1. Moreover, the repository has to serve resources from both worlds:
both those that require that the chain be installed, and those that don’t.
For the former case, where all intermediate certificates also have to be installed in the trust
repository on the server side, the client’s other intermediate CAs will not be trusted, and there is
less need for the RPDNC for the CAs.

7.4 Multi-tier issuing hierarchy

[Requirements 4.2, 4.5, 4.6, 4.8]

This Example continues Example 6.3. Suppose in addition to the validation chain CA1-1  CA1
11
 Root, all these CAs also issue end entity certificates , and that CA1-1 only is trusted to issue
EE certificates for the Grid. (If CA1-1 also issues CA certificates, then, as in Example 6.3,
RPDNC for CA1-1 must now prevent untrusted subordinates under CA1-1 from being inserted
into validation chains for applications that do not need the whole path in the trust repository.)
We now need to exclude EE certificates from CA1 and Root from being trusted on the Grid.
Currently, this is best done by restricting the namespaces with RPDNC.

7.5 Policy Root

Root

CA1 … CAn

[Requirements 4.3]
Suppose the Root is defines its policy so each of the subordinates can be accredited without
11
It may seem far fetched to have CAs that issue both certificates to subordinates and to end
entities, but this example is built on a real case.

caops-wg@ogf.org 8
GFD-I.189 June 6, 2011

being reviewed individually but the subordinate hierarchy is dynamic, e.g., because they are short
lived (naturally, this would only work for applications that do not require the trust chain installed
on the server side). In this case, we want the RPDNC for the Root to be able to accommodate a
range of subordinates whose names are not necessarily known in advance. A related use case is
where a CA operates with more than one CA certificate (with different names) which issue in the
same namespace.

7.6 Improving Grid security through namespaces

[Requirements 4.4, 4.9]

RPDNC can limit the impact of security incidents. Suppose a CA (certificate) X has signed Y and
X is compromised – not necessarily the certificate itself but more likely the CA’s processes. An
attacker obtaining Y1 signed by X will not be able to use Y1 unless the name of Y1 is accepted by
X’s RPDNC.

Since Grid resources must have Y installed along with X in their trusted repositories, they will not
a priori trust Y1. To make use of Y1 on the Grid, the attacker must make Y1 an end entity
certificate, but the name of Y1 must still be accepted by the RPDNC. It thus limits the scope of the
incident.

7.7 Distinguishing types of clients

[Requirements 4.2, 4.6]

A Grid CA can currently issue certificates to users (individual persons), hosts, and robots
(automated clients). These certificates are typically issued under a single policy, with a single set
of OIDs common to them. If an RP wants to distinguish between these, they have to be
distinguished by DN (there is no single rule that will work for all CAs, but for each individual CA it
is usually possible to derive rules that will match accordingly).
A RP will then wish to match against not just the fixed part of the DN, but also the variable part, to
ensure that only the CN (and potentially other parts of the variable space) match the clients the
RP wishes to let in. For example, current implementations have a CN containing “Robot:” for
robot certificates (in a scheme designed not collide with the DN of a person who might be named
“Robot”).

7.8 Combining and the unknown

[Requirement 4.2, 4.11]

We refer again to the diagram in Example 6.3. If we assume CA2 is IGTF-accredited and
therefore trusted internationally, but CA1 issues certificates to national subordinate CAs which
are trusted only by the national Grid.
In this case, the Root has an RPDNC which permits only CA2, but the national RP will want the
branch under CA1 accepted as well. However, the national RPs will refresh IGTF CAs directly
from a suitable repository, but install the national CAs manually. The IGTF repository will include
a IGTF-approved RPDNC permitting the Root to sign only CA2. If the Root has a single RPDNC,
then this will conflict with (or overwrite) the national Root RPDNC which permits also CA1.
12
Suppose instead the IGTF Root RPDNC returns ‘unknown’ for CA1, and the RPDNC PDP
permits multiple RPDNC in a well defined sequence. In this case, the national Grid can have a
second RPDNC which accepts CA2. On the national Grids, the default IGTF RPDNC for Root will
return unknown for CA1, which a policy decision point (PDP) then passes to the second RPDNC
for Root, which then is able to take a decision and accept CA1. Naturally, a PDP must deny DNs
that ultimately end up being unknown, with no further RPDNC to process.
The advantage of this scheme is that both international and national RPs can use the same IGTF
release, and the national modifications need only be installed once.

12
Depending on an eventual implementation, see appendix A.

caops-wg@ogf.org 9
GFD-I.189 June 6, 2011

8 Security Considerations

The namespace policy is an integral part of the security and protection mechanisms of a relying
party, and as such should be protected from tampering at all times. Inadvertent or malicious
modification of a RPDNC policy can lead to namespace collisions, resulting in incorrect subject
being authorized, or may expose a relying party to credentials issues under policies that are
inappropriate or unacceptable, or to denial-of-service.

In case the namespace constraints policy is distributed to the relying party by a third party, this
distribution mechanism must be integrity-protected and protected from denial-of-service. Once
obtained by the relying party, it should be adequately protected from tampering. It is
acknowledged that these requirements are the same as those for the distribution of trust anchors,
and are affected by similar boot-strap issues.

A different between the RPDNC and the actual namespace used by the CA is not indicative of
any lack of trust or lack of trustworthiness of the CA, but merely reflects the decision of a relying
party or their agent(s). The reasons for an RPDNC may be local, e.g., to prevent name space
overlaps between the CAs accepted by an RP, or to select identities that comply with specific
policies.

9 Contributors

The document is a work of the OGF CA Operations Working Group with contributions by the
members of the International Grid Trust Federation (IGTF, see www.gridpma.org)

The editors,
David L. Groep, Nikhef, davidg at nikhef.nl
Jens Jensen, RAL, j.jensen.ral at gmail.com

Intellectual Property Statement

The OGF takes no position regarding the validity or scope of any intellectual property or other
rights that might be claimed to pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights might or might not be
available; neither does it represent that it has made any effort to identify any such rights. Copies
of claims of rights made available for publication and any assurances of licenses to be made
available, or the result of an attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this specification can be obtained from the
OGF Secretariat.

The OGF invites any interested party to bring to its attention any copyrights, patents or patent
applications, or other proprietary rights which may cover technology that may be required to
practice this recommendation. Please address the information to the OGF Executive Director.

Disclaimer
This document and the information contained herein is provided on an “As Is” basis and the OGF
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.

Full Copyright Notice

caops-wg@ogf.org 10
GFD-I.189 June 6, 2011

Copyright (C) Open Grid Forum (2006-2011). 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 OGF or other organizations, except as needed for the purpose of
developing Grid Recommendations in which case the procedures for copyrights defined in the
OGF Document 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 OGF or its
successors or assignees.

References

[EACL]
Anonymous (the Globus Toolkit Authors) Extended Access Control List (EACL) Format
Specification (as stored on http://www.eugridpma.org/documentation/eacl-signing-policy-
format.txt)
[GT]
Globus Alliance The Globus Toolkit http://www.globus.org/
[IGTF]
The International Grid Trust Federation http://www.igtf.net/
[NS96]
D.L. Groep Namespaces Format Specification EUGridPMA Technical Documentation Series,
2006 (http://www.eugridpma.org/documentation/)
[RFC4158]
M. Cooper et al. Internet X.509 Public Key Infrastructure: Certificate Path Building: RFC
4158. September 1995.

caops-wg@ogf.org 11
GFD-I.189 June 6, 2011

Appendix A

This appendix describes additional suggestions for implementing or drafting an RPDNC policy
language, but is explicitly non-normative.

The dynamic policy extension requirement 4.11 can be implemented in various ways, with the
example in this appendix being a possible implementation.

A.1 Dynamic Policy Extension

If no specific RPDNC is not defined for a particular part of the Namespace, it can be extended to
the full namespace either by a default-deny policy, or a default-unknown policy. A default deny
will be fail-safe, but limits the possibility for a relying party to combine RPDNCs from various
providers. A default-unknown policy will allow combination or RPDNCs from multiple providers. A
default-deny should then be applied only if none of the policies applicable to a trust anchor failed
to render a decision. A default-unknown policy, with ultimate deny, is considered to be the most
practical.
The order of evaluation of the sequence is then significant.

caops-wg@ogf.org 12