[caops-wg] X.509 Name constraints
David Chadwick
d.w.chadwick at kent.ac.uk
Mon Oct 22 04:55:36 CDT 2007
Dear Christos
concerning name constraints in the draft 2009 edition of X.509, a new
extension has been added called holder name constraints, rather than
changing the existing specification. This is so that existing PKI
implementations are not affected.
The proposed new extension is copied below. You will notice that the
extension as currently defined only applies to X.509 ACs rather than to
PKCs as well. This is because the work item on X.509 (2009) is only
concerned with enhancements to ACs and not to PKCs. However, in your
case, as I understand it, the name constraints are not to be inserted
into a certificate, but rather are to be set by the RP as an input
parameter to the certificate path processing algorithm. In this case,
the ASN.1 contstruct below may satisfy your needs, and the text can be
changes appropriately to reflect it is set by the RP as input to cert
path processing.
I hope this is of help to you.
regards
David
15.6.2.3 Holder Name Constraints Extension
This extension constrains the name forms and name spaces in which a
subordinate AA or a remote SOA and its subordinate AAs can issue ACs.
This extension, indicates that constraints are being placed on the name
forms and name spaces of all name forms in ACs issued by this AA and all
subsequent AAs in the AC chain. If this extension is absent from all ACs
in an AC chain, then no constraints are placed on any name spaces in the
AC chain. If this extension is present in an AC certificate, then
constraints are automatically placed on the name spaces of every name
form in the AC chain from this point onwards, regardless of whether the
name form is explicitly included in the extension or not i.e. the
default constraint on each name form is exclude all the name space.
NOTE – Because there can be an unbounded set of registeredID name forms
then it is not possible for new name forms to be unconstrained once this
extension is present, without the name form being explicitly included in
this extension via a permitted subtree.
This field is defined as follows:
holderNameConstraints EXTENSION ::= {
SYNTAX HolderNameConstraintsSyntax
IDENTIFIED BY id-ce-nameConstraints }
HolderNameConstraintsSyntax ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
The permittedSubtrees and excludedSubtrees components each specify one
or more naming subtrees of one or more name forms. Each subtree is
defined by the name of the root of the subtree, i.e. the base component,
and, optionally, within that subtree, an area that is bounded by upper
and/or lower levels.
An empty DN sequence is equivalent to a wildcard and means that all DNs
fall within the subtree.
The minimum field specifies the upper bound of the area within the
subtree. All names whose final name component is above the level
specified are not contained within the area. A value of minimum equal to
zero (the default) corresponds to the base, i.e. the top node of the
subtree. For example, if minimum is set to one, then the naming subtree
excludes the base node but includes subordinate nodes.
The maximum field specifies the lower bound of the area within the
subtree. All names whose last component is below the level specified are
not contained within the area. A value of maximum of zero corresponds to
the base, i.e. the top of the subtree. An absent maximum component
indicates that no lower limit should be imposed on the area within the
subtree. For example, if maximum is set to one, then the naming subtree
excludes all nodes except the subtree base and its immediate subordinates.
The permittedSubtrees component is used to reduce the constraints placed
on the name spaces of one or more name forms. Since the entire name
space of each form is automatically fully excluded when this extension
appears in an AA certificate, the permittedSubtrees component describes
the name space(s) that is(are) permitted. If an entire name space of a
particular name form is to be permitted, this is achieved by setting the
base component to the root of the name space.
The optional excludedSubtrees component is used to exclude one or more
subordinate subtrees from the permittedSubtrees. For example, if in the
X.500 distinguished name space, the subtree C=GB is permitted, but the
subtrees C=GB, O=XYZ and C=GB, O=ABC are not permitted, then the
permittedSubtrees will be set to C=GB and the excludedSubtrees will be
set to C=GB, O=XYZ and C=GB, O=ABC. If the excludedSubtrees is present
and its name spaces overlap with the permittedSubtrees, the
excludedSubtrees statement takes precedence.
All holder names in subsequent ACs in a certification path shall be
located in the permitted name spaces for the certificate to be
acceptable. When a certificate holder has multiple names of the same
name form then all such names shall be located in the permitted name
space of that name form for the certificate to be acceptable. When a
certificate holder has multiple names in different name forms, each name
shall be located in the permitted name space of that name form for the
certificate to be acceptable.
Of the name forms available through the GeneralName type, only those
name forms that have a well-defined hierarchical structure may be used
in these fields.
The directoryName name form satisfies this requirement; when using this
name form a naming subtree corresponds to a DIT subtree. An AC is
considered subordinate to the base (and therefore a candidate to be
within the subtree) if the SEQUENCE of RDNs, which forms the full DN in
base, matches the initial SEQUENCE of the same number of RDNs which
forms the first part of the DN of the holder of the certificate. The DN
of the holder of the certificate may have additional trailing RDNs in
its sequence that do not appear in the DN in base. The
distinguishedNameMatch matching rule is used to compare the value of
base with the initial sequence of RDNs in the DN of the subject of the
certificate.
Conformant implementations are not required to recognize all possible
name forms. If an AC using implementation does not recognize a name form
used in any base component, and
- that name form also occurs in the holder field of a subsequent AC in
the chain then that AC shall be handled as if an unrecognized critical
extension had been encountered; or
- that name form does not occur in the holder field of a subsequent AC
in the chain then this name form can be ignored.
If an AC using implementation does not recognize a name form that occurs
in the holder field of a subsequent AC in the chain from that in which
this extension appeared, but that name form does not occur in any base
component of this extension, then that AC shall be rejected.
This extension shall always be critical.
An AC using system shall check that the attribute certificate path being
processed is within the constraints specified by the value in this
extension.
Christos Kanellopoulos wrote:
> Dear all,
>
> Find below a draft version of the minutes from the CAOPS session on
> 16.10.2007. Please review them and send any comment to the list. On
> Wednesday 23.10.2007 I will upload it on GridForge.
>
> -C.
>
> CAOPS Session OGF 21 16.10.2007
> -------------------------------------
>
> Note Takers: Licia Florio, Christos Kanellopoulos
>
> -------------------------------------
>
>
> David Groep: Grid Certificate Profile
> .....................................
>
> x The document has finished the public comment period as of October 8.
>
> A1: David Groep to send email to the CAOPS mailing list with answers to
> the comments
> A2: Christos Kanellopoulos to test IE7 with CA certificate that has been
> reissued
> A3: By Nov 6 a new version of the document should be available that will
> address all the comments. There is going to be one week afterwards for
> group comments and then it will be pushed to the editor's queue.
>
>
>
> Yoshio Tanaka: Audit Document
> ..............................
>
> x New version of the document was uploaded to GridForge
>
> - Christos Kanellopoulos: The document should provide a generic
> framework for performing audits on Grid IdPs. We should remove any
> statements on the preferred answers for each question in the document
> - Mike Helm: This look very much like the spreadsheet that is being used
> within TAGPMA for CA accreditation.
>
> A4: Mike Helm to send the spreadsheet template at the CAOPS mailing lists
> A5: By end of November a new version of the document should be ready.
> Christos Kanellopoulos to help with the editing.
>
>
> David Groep: Name Constraints
> ..............................
>
> x Still waiting for the replies from the people at OGF 20 CAOPS session
> x The implementation details will be stripped off from the document and
> it will be focused on the requirements for providing namespace
> constraints at the policy lave.
>
> - David Chadwick: What we want to achieve with this document can be
> found in the initial X.509 specs that got completely twisted around '97.
> This is expected to be changed in the new versions of the X.509 document
> - David Chadwick: Wild-card matching, as it is expressed in the
> document, did not exist in the X.500 specs. Subtree matching was part of
> the specs though
> - David Groep: We've added wild-card matching exactly to perform subtree
> matching
>
> A6: David Chadwick to send details at the CAOPS mailing list
> A7: David Groep to update the document with reference to the documents
> that David Chadwick will (if and where necessary)
>
> - Rachana Ananthakrishna: Globus will implement Namespace policies
> within 2008 Q1. Going to use the current policy language
> - David Groep: suggested that Globus eliminates the 1024 char limitation.
>
> A8: New version of the document by late December
>
> Mike Helm: OCSP Requirements for Grids
> ......................................
>
> x The document was derailed from its initial scope during its
> development in the past two years.
> x We should revisit the document focusing on the Trusted Responder concept.
> x There is a lot of useful information within the document that could be
> used in future documents.
> x There is some work done in IETF that supersedes the document. However
> it is worth to look at Trusted Responder. Seems like the current trend
> is to use CRLs or short-lived certificates.
>
> - Mike Helm: Users seem to be happy with the current CRL solution. Even
> when they face problems, they prefer to (over) engineer around them.
> - Rachana Ananthakrishna: In order for Globus to start working on an
> implementation, they need to have specific requirements from the users
>
> A9: Mike Helm: New draft document by early January
>
>
> ------------------------------------------------------------------------
>
> --
> caops-wg mailing list
> caops-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/caops-wg
--
*****************************************************************
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
*****************************************************************
More information about the caops-wg
mailing list