ANSI X9F1 is developing a draft standard to specify X.509 extensions for use in
the new X.509 Extensions field. To date, X9 and ISO/IEC JTC1/SC21 have
succeeded in maintaining alignment of their standard extensions. Following is
the latest X9 draft, produced on the basis of editing instructions from the Oct
25-27 X9F1 meeting.
Efforts have been made to accommodate comments on the previous draft from
subscribers to this list. Further comments will be appreciated.
Warwick Ford
-------------------------------------
Accredited Standards Committee X9 November 6, 1994
Title: X9 - Financial Services
Accredited by the American National Standards Institute
PROPOSED WORKING DRAFT
AMERICAN NATIONAL STANDARD
X9.xx-1994
PUBLIC KEY CRYPTOGRAPHY FOR THE FINANCIAL SERVICES INDUSTRY:
EXTENSIONS TO PUBLIC KEY CERTIFICATES
1. Scope
This Standard specifies extensions to the definitions of
public-key certificates in ANSI X9.30-3 and X9.31-3. These
extensions are in the following areas:
a) extensions to certificates to convey additional
information about the keys being certified, including
key identifiers and indicators of approved key usage;
b) extensions to certificates to support certification of
secondary public keys used for different purposes than
the primary public key;
c) extensions to certificates to convey additional
attribute information about the subject of the
certificate;
d) extensions to certificates to allow policy identifiers
and constraint specifications to be included in CA-
certificates, i.e., certificates for CAs issued by
other CAs, to facilitate the automated processing of
certificate chains when multiple certification policies
are involved (e.g., when policies vary in different
user institutions or when interoperation with external
public-key infrastructures occurs).
This Standard includes specifications of the extension
fields, descriptions of the underlying requirements, and
descriptions of their intended use.
2. Definitions and Common Abbreviations
2.1. Definitions
CA-certificate A certificate for one CA issued by
another CA.
certification policy A set of policy statements
relating to use of a certificate
recognized by both the issuer and user
of the certificate.
policy mapping Recognition that, when a CA in one
security domain certifies a CA in
another security domain, a particular
certification policy in the second
domain may be considered by the
authority of the first domain to be
equivalent (but not necessarily
identical in all respects) to a
particular certification policy in the
first domain.
security domain A set of elements, a security
policy, a security authority and a set
of security-relevant activities in which
the the set of elements are subject to
the security policy, administered by the
security authority, for the specified
activities.
2.2. Abbreviations and Acronyms
CA Certification Authority
PCMCIA Personal Computer Memory Card
International Association
PEM Privacy Enhanced Mail
TCB Trusted Computing Base
3. Introduction
A public-key certificate is a data structure, digitally
signed by a certification authority (also known as the
certificate issuer), which binds a public-key value to the
identity of the entity which holds the corresponding
private key. The latter entity is known as the subject of
the certificate.
A public-key user needs to obtain and validate a certificate
containing the required public key. If the public-key user
does not already hold an assured copy of the public key of
the certification authority that signed the certificate,
then it might need an additional certificate to obtain that
public key. In general, a chain of multiple certificates
may be needed, comprising a certificate of the public-key
owner signed by one certification authority, and zero or
more additional certificates of certification authorities
signed by other certification authorities. Chains are
required because a public-key user is only initialized with
a limited number (often one) of assured certification
authority public keys.
This Standard specifies extensions to the definitions of
public-key certificates in ANSI X9.30-3. These extensions
are in the following areas:
a) Key Information: These extensions convey additional
information about the subject and issuer keys, such as
key identifiers and indicators of approved key usage.
They facilitate the implementation of public-key
infrastructures and allow administrators to limit the
purposes for which certified keys are used.
b) Secondary Public Keys: These extensions support
certification of secondary public keys used for
different purposes than the primary public key. For
example, they allow a certificate for a digital
signature key to also carry a key for encryption-key
establishment.
c) Subject Attributes: These extensions convey additional
attribute information about the subject of the
certificate. The subject name in a certificate conveys
limited information and may not be sufficient for a
certificate user to be confident that the certificate
applies to a particular person or device. These
extensions allow additional information to be carried
for this purpose.
d) Chain Processing Controls: These extensions allow
certification policy identifiers and constraint
specifications to be included in CA-certificates, i.e.,
certificates for CAs issued by other CAs, to facilitate
the automated processing of certificate chains when
multiple security policies are involved (e.g., when
policies vary in different user institutions or when
interoperation with external public-key infrastructures
occurs). The constraints may restrict the types of
certificates which can be issued by the subject CA or
which may occur subsequently in a certificate chain.
The approach proposed does not require certificate
chain processing functions to have any knowledge of
specific policies. (Certificate-issuing systems do
require such knowledge.)
The extension fields are designed for use in an automated
self-contained implementation of certification chain
processing logic. No local user interaction is necessary
and no accesses to trusted local databases are required,
beyond the need to obtain a trusted copy of an initial
public key.
Use of each extension is at the option of the certificate
authority generating a certificate. Extensions are
recognized as being either critical or non-critical. If a
critical extension is included in a certificate, then the
certificate user shall process this field or, if the
particular extension field type is not recognized by the
implementation, reject the certificate. A certificate user
is permitted to ignore a non-critical extension.
4. Key Information
4.1 Requirements
The following requirements regarding certificate extension
fields need to be accommodated:
a) Recognizing that a CA will periodically update its key
pair, there is a requirement to positively identify the
public key used to sign any certificate. The
certificate verifier needs to use such identifier in
determining the right CA-certificate to use to validate
the signature on a certificate. Such identification
needs to be included in a public key certificate.
b) A CA needs to be able to securely associate a public
key with a particular restricted usage, e.g., digital
signature, encryption key transport, encryption key
agreement. Correct usage needs to be checkable by a
public-key certificate user.
c) In general, a certificate subject has different public
keys and, correspondingly, different certificates for
different purposes, e.g., digital signature, encryption
key transport, encryption key agreement. A certificate
field is needed to assist a public-key certificate user
in selecting the correct certificate for a given
subject for a particular purpose. (NOTE: This differs
from requirement a) in that it is an aid to certificate
users rather than a usage restriction.)
d) Recognizing that a subject will periodically update its
key pair,there is a requirement to positively identify
different public keys for the same subject used at
different points in time. The public-key user needs to
use such identifier in determining the right
certificate to use. Such identification needs to be
included in a public key certificate.
e) The private key corresponding to a certified public key
may have a valid use period different to the validity
of the public key. (With digital signature keys, the
validity period for the signing private key is
typically much shorter than that for the verifying
public key.) In the event of a private key compromise,
the period of exposure can be limited if the signature
verifier knows the legitimate use period for the
private key. There is therefore a requirement for the
public key user to be able to know the validity period
of the private key.
f) There is a need to be able to tag keys with indicators
of privileges associated with their use. The semantics
associated with tags need to be based on privately
registered schemes not subject to standardization.
4.2 Certificate Extension Fields
The following certificate extension fields are defined:
a) AuthorityKeyIdentifier: This field enables distinct
keys used by the same certification authority to be
differentiated (e.g., as key updating occurs). The key
may be identified by an explicit key identifier, by
identification of a certificate for the key (giving
certificate issuer and certificate serial number), or
both.
b) KeyUsageRestriction: This field indicates a
restriction imposed as to the purpose for which the
certified public key may be used.
c) PrimaryKeyAttributes: This field provides for the
transfer of optional additional information about the
primary public key being certified. It can include a
key identifier, an indication of the intended use of
that key (without the requirement that use must be
restricted to this purpose), and/or an indication of
the valid period of use of the corresponding private
key.
d) Privileges: This field associates privilege indicators
with a certified key according to a private privilege
recognition scheme.
All of the above extensions are applicable to both CA-
certificates and end-entity certificates.
4.2.1 Authority Key Identifier Field
This field enables distinct keys used by the same
certification authority to be differentiated (e.g., as key
updating occurs). The key may be identified by an explicit
key identifier, by identification of a certificate for the
key (giving certificate issuer and certificate serial
number), or both. The following ASN.1 type defines this
field:
AuthorityKeyIdentifier EXTENSION ::= {
SYNTAX AuthorityKeyId
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
AuthorityKeyId ::= SEQUENCE {
keyIdentifier KeyIdentifier OPTIONAL,
certIssuer Name OPTIONAL,
certSerialNumber CertificateSerialNumber
OPTIONAL }
KeyIdentifier ::= OCTET STRING
4.2.2 Key Usage Restriction Field
This field indicates a restriction imposed as to the purpose
for which the certified public key may be used. The
following ASN.1 type defines this field:
KeyUsageRestriction EXTENSION ::= {
SYNTAX KeyUsage
CRITICAL TRUE
IDENTIFIED BY { OID TBA } }
KeyUsage ::= CHOICE {
userKeyUsage UserKeyUsage,
cAKeyUsage CAKeyUsage }
UserKeyUsage ::= BIT STRING {
userAuthentication (0), -- for digital signatures for
-- authentication purposes
keyEncryption (1), -- for encrypting keys
-- for transfer
dataEncryption (2), -- for encrypting user data
keyAgreement (3) -- for key agreement exchange
nonRepudiation (4) } -- for digital signature
-- for nonrepudiation
CAKeyUsage ::= BIT STRING {
keyCertSign (0), -- for a CA to sign public key
-- certificates
offLineCRLSign (1), -- for a CA to sign a CRL for
-- off-line (e.g., Directory)
-- distribution
onLineCRLSign (2), -- for a CA to sign a CRL for
-- distribution through an
-- on-line transaction
transactionSign (3) } -- for a CA to sign on-line
-- administration transactions
The KeyUsageRestriction field serves to distinguish a CA-
certificate from an end-entity certificate. The cAKeyUsage
option must be used if the subject is permitted to act as a
CA. UserKeyUsage values may be used to control key usage in
end systems and/or to distinguish between multiple
certificates for the same subject with keys intended for
different purposes.
4.2.3 Primary Key Attributes Field
This field provides for the transfer of optional additional
information about the primary public key being certified.
It can include a key identifier, an indication of the
intended use of that key (without the requirement that use
must be restricted to this purpose), and/or an indication of
the valid period of use of the corresponding private key.
The following ASN.1 type defines this field:
PrimaryKeyAttributes EXTENSION ::= {
SYNTAX KeyAttributes
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
KeyAttributes ::= SEQUENCE {
keyIdentifier KeyIdentifier OPTIONAL,
keyUsage KeyUsage OPTIONAL,
privateKeyValidity Validity OPTIONAL }
4.2.4 Primary Key Privileges Field
This field associates privilege indicators with a certified
key according to a private privilege recognition scheme.
The following ASN.1 type defines this field:
PrimaryKeyPrivileges EXTENSION ::= {
SYNTAX PrivilegeSyntax
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
PrivilegeSyntax ::= SEQUENCE {
privilegeAuthorityId OBJECT IDENTIFIER,
privilegeFlags BIT STRING }
5. Secondary Public Keys
5.1 Requirements
It should be possible to convey in a certificate more than
one public key for different algorithms and/or different key
usage purposes.
Example: One certificate for one user can convey a key for
a key establishment algorithm as well as a distinct key for
a digital signature algorithm.
5.2 Certificate Extension Fields
One certificate extension field called SecondaryPublicKey is
defined. It is applicable to both CA-certificates and end-
entity certificates. The following ASN.1 type defines this
field:
SecondaryPublicKey EXTENSION ::= {
SYNTAX SecondaryPublicKeyInfo
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
SecondaryPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
keyUsageRestriction KeyUsage OPTIONAL,
keyAttributes KeyAttributes OPTIONAL,
privilegeAuthorityId OBJECT IDENTIFIER OPTIONAL,
privilegeFlags BIT STRING OPTIONAL,
secondaryPublicKey BIT STRING }
6. Subject Attributes
6.1 Requirements
The following requirements regarding certificate extension
fields need to be accommodated:
a) For use of certificates in conjunction with
applications based on Internet electronic mail, it is
necessary to be able to securely associate an Internet
mail address (RFC822 name) with a certificate subject.
b) For use of certificates in conjunction with
applications based on X.400 electronic mail, it is
necessary to be able to securely associate an X.400
mail address (Originator/Recipient address) with a
certificate subject.
c) A certificate user may need to securely know certain
identifying information about a subject in order to
have confidence that the subject is indeed the person
intended. For example, information such as postal
address, position in a corporation, or a picture image
may be required. Such information may be conveniently
represented as X.500 attributes, but these attributes
are not necessarily part of the distinguished name.
There is therefore a need for a certificate field to
convey additional X.500 attributes beyond those in the
distinguished name.
d) In order to know which algorithms to use prior to
attempting to establish secure communications with a
subject, there is a need for an indication in a
certificate of the algorithms the subject supports.
This requirement applies particularly to encryption
algorithms, but it may be useful to be able to indicate
any type of cryptographic algorithm supported.
e) In order for a certificate user to securely know the
clearance(s) of a subject when using a multi-level
access control scheme, it is necessary for a
certificate to be able to convey an indication of such
clearance(s).
6.2 Certificate Extension Fields
The following certificate extension fields are defined:
a) InternetMailName: This field provides an Internet
RFC822 mail name for the subject of the certificate.
It is applicable to both CA-certificates and end-entity
certificates.
b) X400Address: This field provides an X.400 O/R Address
for the subject of the certificate. It is applicable
to both CA-certificates and end-entity certificates.
c) DirectoryAttributes: This field conveys any desired
X.500 attribute values for the subject of the
certificate. It is applicable to both CA-certificates
and end-entity certificates.
d) SupportedAlgorithms: This field indicates algorithms
supported by the subject of the certificate. It is
applicable to both CA-certificates and end-entity
certificates.
e) Clearances: This field indicates clearances of the
subject of the certificate, for use with multi-level
access control schemes. It is applicable to end-entity
certificates only.
6.2.1 Internet Mail Name Field
This field provides an Internet RFC822 mail name for the
subject of the certificate. The following ASN.1 type
defines this field:
InternetMailName EXTENSION ::= {
SYNTAX RFC822Name
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
RFC822Name ::= IA5String
6.2.2 X.400 Address Field
This field provides an X.400 O/R Address for the subject of
the certificate. The following ASN.1 type defines this
field:
X400Address EXTENSION ::= {
SYNTAX ORAddress
-- Imported from X.400
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
6.2.3 Directory Attributes Field
This field conveys any desired X.500 attribute values for
the subject of the certificate. The following ASN.1 type
defines this field:
DirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
AttributesSyntax ::= SEQUENCE OF Attribute
-- Imported from X.501
InformationFramework
6.2.4 SupportedAlgorithms Field
This field indicates algorithms supported by the subject of
the certificate. The following ASN.1 type defines this
field:
SupportedAlgorithms EXTENSION ::= {
SYNTAX SupportedAlgorithmsSyntax
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
SupportedAlgorithmsSyntax ::= SEQUENCE OF
AlgorithmIdentifier
-- Imported from X.509
6.2.5 Clearances Field
This field indicates clearances of the subject of the
certificate, for use with multi-level access control
schemes. The following ASN.1 type defines this field:
Clearances EXTENSION ::= {
SYNTAX ClearanceSyntax
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
ClearanceSyntax ::= BIT STRING {
topSecret (0),
secret (1),
confidential (2),
restricted (3),
unclassSensitive (4),
canadaProtectedC (5),
canadaProtectedB (6),
canadaProtectedA (7),
companyProprietary (8),
unclassified (9) }
7. Chain Processing Controls
In general, processing of a certificate chain needs to
consider the trust associated with each certificate. If one
homogeneous certification policy applies to all certificates
this is not an issue. However, when multiple security
policies are involved (e.g., when policies vary in different
financial institutions or when interoperation with external
organizations occurs) certificate chain processing requires
additional information to be made available, either from the
certificates themselves or from local sources. This
standard specifies a means for conveying requisite
information within the certificates themselves.
The development of this Standard takes into account the
requirements described below.
7.1 General Chain-Processing Requirements
In any public-key user system, including digital signature
verification systems and systems which perform public-key-
based encryption, processing of a certificate chain is a
high-assurance task. The implementation of the chain
processing function must be resistant to software-tampering
or data modification attacks. If such attacks are possible,
then it may be possible for an intruder to forge any digital
signature being verified or to masquerade as a party to whom
confidential data is to be sent1. Furthermore, chain
processing functions should be suitable for implementation
in hardware cryptographic modules such as cryptographic
PCMCIA cards or smart cards.
The following requirements regarding certificate chain
processing need to be accommodated:
a) Certificate chain processing needs to be automatable
and self-contained. This is necessary to permit
trusted hardware or software modules to be implemented
which perform the certificate chain processing
functions.
b) Certificate chain processing must not depend upon real-
time interactions with the local user.
c) Certificate chain processing must not depend upon the
use of trusted local databases of policy-description
information. (Some trusted local information - an
initial public key, at least - is needed for
certificate chain processing but the amount of such
information should be minimized.)
d) Maximal policy freedom is required. A security domain
must be able to stipulate which CAs in other domains it
trusts and for which purposes. Chaining through
multiple policy domains must be supported.
e) Complete flexibility in trust models is required. A
strict hierarchical model which is adequate for a
single organization is not adequate when considering
the needs of governments internationally nor when
considering the needs of non-government enterprises.
f) Key-pair updating, on a regular or exceptional-
condition basis, shall not be precluded (or made unduly
difficult) for any CA.
g) Flexibility is required in selection of the first
trusted CA in a chain processed by any public-key user
system. In particular, it shall be possible to require
that the chain start in the local security domain of
the public-key user system.
g) Naming must not be artificially constrained, i.e.,
X.500 name structures considered natural for
organizations or geographical areas must not need
adjustment in order to accommodate certification
authority requirements.
h) Any extended system introduced should be backward-
compatible with the unconstrained X.509 system (as
specified in 1988 and 1993 versions of ISO/IEC 9594-8
or X.509) and with the Internet Privacy Enhanced Mail
(PEM) system [1].
7.2 Policy Requirements
The following requirements relate to policies:
a) Certificate chains need to be able to span multiple
security domains.
b) Within a security domain, it must be possible to
support multiple certification policies.
c) There must be support for relationships between
security domains which allow two domains to trust each
other with respect to a particular certification policy
or with respect to different, but compatible,
certification policies.
d) Because one domain may not be prepared to fully trust
lower-level CAs in another domain, it must be possible
for a CA certifying another CA to specify constraints
on what certificates the latter CA may issue, e.g.,
constraints on the name space for which certificates
may be issued. Furthermore, adherence to these
constraints must be automatically checkable by the
certificate user.
7.3 Certification Policies and Constraints
A typical certificate chain is illustrated in Figure 1.
Figure 1: Typical Certificate Chain
7.3.1 Identified Certification Policies
Certification policies are identified collections of policy
statements which are not, in general, specifiable in terms
recognizable by automated certificate chain processing
systems. For example, an identifiable policy may imply
particular procedures used in authenticating certified
entities, assurance levels of equipment employed, and/or
liability assumed by the certifying party.
An identified policy may imply rules for which adherence can
be verified by particular applications. For example,
different identified policies may apply to financial
transactions in the dollar ranges of $1-$9,999, $10,000 to
$1,000,000, and above $1,000,000; use of the correct policy
identifier can be checked by the financial application
(which has knowledge of both the transaction value and the
policy semantics) but cannot be checked by the base
certificate-chain verification logic.
Each identified policy is assigned a globally-unique ASN.1
object identifier. There may be multiple policies defined
and used within a single domain and one policy may be used
across multiple domains, if suitable agreements exist.
7.3.2 Policy Mapping
When cross-certifying from one domain to another, it is
sometimes acceptable (either unilaterally or mutually) to
recognize an equivalence mapping from one identified policy
to another. For example, the U.S. government domain may
have a policy called "Canadian Trade" and the Canadian
government may have a policy called "U.S. Trade"; while the
two policies are distinctly identified and defined, there
may be an agreement between the two governments to accept
certificate chains extending cross-border within the rules
implied by these policies for relevant purposes.
Policy mapping implies significant administrative overheads
and the involvement of suitably diligent and authorized
personnel in related decision-making. In general, it is
preferable to agree upon more global use of common policies
than it is to apply policy mapping. For example, it would
be preferable for the U.S., Canada, and Mexico to agree upon
a common policy for "North American Trade".
7.3.3 CA Constraints
CA constraints are used to provide assurances that a CA in
the chain is not violating rules stipulated by more trusted
CAs, i.e., CAs closer to the chain start. Constraints
applied to a CA may relate to the subject namespace, to the
key-usage purposes, and to the algorithms for which that CA
may issue certificates.
The most important use of CA constraints will be in
restricting the name space for which a CA can certify. In
this respect, CA constraints fulfill a similar function to
the PEM name subordination rule, but provide for much
greater flexibility in naming conventions.
7.4 Certificate Extension Fields
This standard defines a set of fields for inclusion in CA-
certificates for the purpose of facilitating certificate
chain processing in multiple-policy environments. The
contents of these fields allow a CA to specify policy-
dependent constraints on the permitted characteristics of
certificates issued by the subject of the CA-certificate and
of subsequent certificates in a certificate chain. This
approach does not require certificate chain processing
functions to have any knowledge of specific policies.
(Certificate-issuing systems do require such knowledge.)
The following certificate extension fields are defined:
a) Policies Field: This field lists identified policies
that the certificate is expressly recognized as
supporting (dependent upon constraints, the certificate
may or may not be usable with other policies as well).
This field is applicable to both CA-certificates and
end-entity certificates.
b) PolicyMappings Field: This field allows a certificate
issuer to indicate that one or more of that issuer's
policies can be considered equivalent to a nominated
policy identifier used in the subject's domain. This
field is applicable to both CA-certificates and end-
entity certificates.
c) AuthorityConstraints Field: This field is applicable
to CA- certificates only. It specifies a set of
constraints to apply with respect to certificates
issued by the CA that is the subject of the immediate
certificate.
7.4.1 Policies Field
This extension field lists issuer-domain policies that the
certificate is expressly recognized as supporting (dependent
upon constraints, the certificate may or may not be usable
with other policies as well). The following ASN.1 type
defines this field:
Policies EXTENSION ::= {
SYNTAX PolicySet
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
PolicySet ::= SEQUENCE OF PolicyId
PolicyId ::= OBJECT IDENTIFIER
-- policyIDs are registered by community-
interest
-- groups or private organizations
7.4.2 Policy Mappings Field
This field allows a certificate issuer to indicate that one
or more of that issuer's policies can be considered
equivalent to a nominated policy identifier used in the
subject's domain. The following ASN.1 type defines this
field:
PolicyMappings EXTENSION ::= {
SYNTAX PolicyMappingSyntax
CRITICAL FALSE
IDENTIFIED BY { OID TBA } }
PolicyMappingSyntax ::= SEQUENCE OF SEQUENCE {
issuerDomainPolicies PolicySet,
subjectDomainPolicy PolicyId }
7.4.3 Authority Constraints Field
This extension field is applicable to CA-certificates only.
It specifies a set of constraints to apply with respect to
certificates issued by the CA that is the subject of the
immediate certificate and/or constraints to apply throughout
the subsequent chain.
The following ASN.1 type defines this field:
AuthorityConstraints EXTENSION ::= {
SYNTAX AuthorityConstraintSyntax
CRITICAL TRUE
IDENTIFIED BY { OID TBA } }
AuthorityConstraintSyntax ::= SEQUENCE OF SEQUENCE {
policySet PolicySet OPTIONAL,
-- If policySet is omitted, constraintSet
-- applies to any policy
constraintSet ConstraintSet }
ConstraintSet ::= SEQUENCE {
certNameConstraint NameConstraint OPTIONAL,
certAlgorithmConstraint AlgorithmConstraint
OPTIONAL,
certExplicitPolicy ExplicitPolicy
DEFAULT notRequired,
certForCAPermitted BOOLEAN DEFAULT TRUE,
certForUserPermitted BOOLEAN DEFAULT TRUE,
endAlgorithmConstraint AlgorithmConstraint
OPTIONAL,
endKeyUsageConstraint KeyUsage OPTIONAL,
chainNameConstraint NameConstraint OPTIONAL,
chainAlgorithmConstraint AlgorithmConstraint OPTIONAL,
chainNameSubordConstraint NameSubordConstraint
DEFAULT noConstraint,
chainLenConstraint ChainLenConstraint OPTIONAL,
nextCertConstraints NextCertConstraints OPTIONAL }
NameConstraint ::= SQUENCE OF SubtreeClassSpecification
-- SubtreeClassSpecification imported from
-- BasicAccessControl module in X.501 --
AlgorithmConstraint ::= SEQUENCE OF AlgorithmIdentifier
-- AlgorithmIdentifier imported from
-- AuthenticationFramework module in X.509 --
ExplicitPolicy ::= ENUMERATED {
required (0), -- Active policy must explicitly
-- appear in policies field
notRequired (1) } -- Active policy need not explicitly
-- appear in policies field
NameSubordConstraint ::= ENUMERATED {
noConstraint (0),
subordinateToCA (1),
subordinateToCAsSuperior (2) }
ChainLenConstraint ::= INTEGER
NextCertConstraints ::= ConstraintSet
Note the following conventions used in the naming of fields:
a) fields beginning "cert..", e.g.,
certAlgorithmConstraint, indicate a constraint applying
to immediate certificates only, i.e., certificates
issued by the subject of the current certificate.
b) fields beginning "end..", e.g., endKeyUsage
indicate a constraint applying to the end-entity
certificate which is the final certificate in the
chain.
c) fields beginning "chain..", e.g.,
chainAlgorithmConstraint indicate a constraint applying
to the chain, and all certificates therein, starting
with any certificate issued by the subject of the
immediate certificate.
The various immediate certificate constraint fields are
interpreted as follows:
certNameConstraint: If this constraint is present,
certificates issued by the subject of this certificate
must be constrained to subjects within one of the
specified subtrees. Unless the
SubtreeClassSpecification contains a chop
specification, a subtree is considered to extend to the
leaves of the Directory Information Tree.
[Editor's note: Diagram to be added to illustrate
SubtreeClassSpecifications in the DIT]
certAlgorithmConstraint: If this constraint is
present, certificates issued by the subject of this
certificate will only be considered valid if signed
using one of the identified algorithms and the
corresponding identified parameters.
certExplicitPolicy: If the value "required" is
specified, the active policy must explicitly appear in
the Policies field of certificates issued by the
subject of this certificate. If the value notRequired
is specified, or if the field is omitted, then the
active policy need not explicitly appear in the
Policies field.
The various end-entity certificate constraint fields are
interpreted as follows:
endAlgorithmConstraint: If this constraint is present,
the certificate chain will only be considered valid for
certifying an end-entity key for use with one of the
identified algorithms and the corresponding identified
parameters.
endKeyUsageConstraint: If this constraint is present,
the end-entity key certified at the end of this
certificate chain can be considered valid only for the
identified key usages.
The various chain-related constraint fields are interpreted
as follows:
chainNameConstraint: If this constraint is present,
certificates issued by the subject of this certificate
plus all subsequent certificates in the chain must be
constrained to subjects within one of the specified
subtrees. Unless the SubtreeClassSpecification
contains a chop specification, a subtree is considered
to extend to the leaves of the DIT.
chainAlgorithmConstraint: If this constraint is
present, all certificates in the chain starting from a
certificate issued by the subject of this certificate
will only be considered valid if signed using one of
the identified algorithms and the corresponding
identified parameters.
chainNameSubordConstraint: Interpretation of this
constraint depends upon the value specified:
If the value subordinateToCA is specified then, in all
certificates in the chain starting from a certificate
issued by the subject of this certificate, the subject
name must be subordinate to the issuer name of the same
certificate.
If the value subordinateToCAsSuperior is specified
then, in all certificates in the chain starting from a
certificate issued by the subject of this certificate,
the subject name must be subordinate to the name of the
immediate superior DIT node of the issuer of the same
certificate.
chainLenConstraint: If this constraint is present,
this constraint gives the maximum number of CA-
certificates that may follow this certificate in a
certificate chain. Value 0 indicates that the subject
of this certificate may issue certificates only to end-
entitys and not to further CAs. If no
chainLenConstraint appears in any certificate of a
chain, there is no limit to the allowed length of the
chain.
nextCertConstraint: If this constraint is present, it
specifies a set of constraints to apply to any
certificate issued by the subject of this certificate.
Note that this constraint can be used recursively,
allowing a CA to constrain the conditions applying to
any point further along a certificate chain. When the
use of nextCertConstraint results in multiple
constraints of the same type applying to a certificate,
the constraints combine such that the aggregate
constraint can become more restrictive but never less
restrictive than any individual constraint.
7.5 Certificate Chain Processing Procedure
The KeyUsage and AuthorityConstraints fields are designed
for use in an automated self-contained implementation of
certification chain processing logic. No local user
interaction is necessary and no accesses to trusted local
databases are required. Following is a description of a
chain processing procedure which satisfies the requirements.
While conforming implementations are not required to
implement this procedure as described, their behaviour shall
be equivalent to that of this procedure.
The inputs to the chain processing procedure are:
y a certificate chain;
y a trusted public key value, or an identifier of such a
key (if the key is stored internally to the chain
processing module), for use in verifying the first
certificate in the chain;
y an initial active policy identifier;
y an initial explicit-policy indicator, which indicates
whether or not the active policy needs to explicitly
appear in the Policies field of the first certificate;
and
y a key usage indicator taking one or more of the values
defined in the KeyUsage ASN.1 type.
The output of the procedure is an indication of either
success or failure of chain validation. If failure, a
diagnostic code indicating the reason for failure is
returned.
In outline, the procedure operates as follows. The initial
step involves:
a) Initialize the active policy indicator to the value
specified by the initial active policy identifier.
b) Initialize the explicit-policy indicator to the value
specified by the initial explicit-policy indicator.
c) Initialize the set of stored constraints to null.
Each certificate is then processed in turn, starting with
that signed using the input trusted public key. The last
certificate is processed as an end-entity certificate; all
other certificates (if any) are processed as CA-
certificates.
Actions performed in processing a CA certificate include:
a) Check that the signature verifies, that dates are
valid, and that the subject and issuer names chain
correctly.
b) If the KeyUsage field is present, check that it permits
CA signature.
c) If explicit-policy indicators so require, check that
the active policy appears in the Policies field.
d) Check that any stored chain constraint is not violated.
e) Check that other stored constraints from earlier
certificates in the chain that are to apply
specifically to this certificate are not violated.
f) Examine the AuthorityConstraints field and process all
constraint sets applying to the active policy. Apply
g) thru j) as appropriate.
g) Store any chain constraint values for use in processing
of the remainder of the chain. Multiple such
constraints encountered throughout chain processing
combine such that the aggregate constraint can become
more restrictive but never less restrictive.
h) Store any certNameConstraint, certAlgorithmConstraint
or certExplicitPolicy details for use in processing the
next certificate.
i) If there is a policyMapping field, set the active
policy to that identified.
j) If there is a nextCertConstraint field, store all
details for use in processing the next certificate.
Actions performed in processing an end-entity certificate
include:
a) Check that the signature verifies, that dates are
valid, and that the subject and issuer names chain
correctly.
b) Check that the KeyUsage field is consistent with the
input key usage indicator and any
chainKeyUsageConstraint stored during chain processing.
c) If the explicit-policy indicator so requires, check
that the active policy appears in the Policies field.
Note that the above outline omits certificate revocation
list processing, which can be considered an additional set
of checks which have to be applied to each certificate to
ensure their validity.
It is possible to specify an extended version of the above
chain processing procedure which results in default
behaviour identical to the rules of Internet PEM as defined
in RFC 1422. In this extended version, additional inputs to
the procedure are a list of one or more Policy Certification
Authority (PCA) names and an indicator of the position in
the chain where the PCA is expected. At the nominated PCA
position, the CA name is compared against this list. If a
recognized PCA name is found then a constraint of
SubordinateToCA is implicitly assumed for the remainder of
the chain and processing continues. If no valid PCA name is
found, and if the chain cannot be validated on the basis of
identified policies, then the chain is considered invalid.
8. References
1. S. Kent, "Privacy Enhancement for Internet Electronic
Mail, Part II: Certificate-Based Key Management", RFC
1422, Internet Activities Board, 1993.
Appendix A: Examples of Use of Identified Policies and CA
Constraints
(This Appendix is included for information only and is not a
part of this Standard.)
NOTE - The examples in this appendix use an informal
notation.
A.1 Example 1: Use of Name and Algorithm Constraints
Suppose the U.S. Government is prepared to cross-certify the
Canadian government with respect to the U.S. policy "US/Can-
Trade", conditional upon:
a) only entities with names under country=Canada may be
certified in chains via a Canadian government CA;
b) all certificates must be signed with the algorithm
"Digital-Signature-Algorithm".
The U.S. government root CA could issue a certificate for a
Canadian government CA with the following extension fields:
Policies =
PolicySet = {"US/Can-Trade"}
AuthorityConstraints =
PolicySet = {"US/Can-Trade"}
ConstraintSet =
{ ChainNameConstraint =
{subtree under country=Canada},
ChainAlgorithmConstraint =
"Digital-Signature-Algorithm" }
A.2 Example 2: Cross-Certification with Policy Mapping
Suppose the following cross-certification scenario is
required between the Canadian and U.S. governments:
a) a Canadian government CA wishes to certify use of US
government signatures with respect to a Canadian policy
called "Can/US-Trade";
b) the U.S. government has a fully-compatible policy
called "US/Can-Trade", which operates only within the
domain of CAs of "US-Dept-of-Commerce";
c) the Canadian government wants to apply safeguards that
require the first U.S. CA to explicitly declare its
support for the "US/Can-Trade" policy and that prohibit
any subsequent cross-certifying outside the "US-Dept-of-
Commerce" naming domain.
The Canadian government root CA could issue a certificate
for a "US-Dept-of-Commerce" CA with the following extension
fields:
Policies =
PolicySet = {"Can/US-Trade"}
PolicyMappings ={
issuerDomainPolicies = {"Can/US-Trade"}
subjectDomainPolicy = "US/Can-Trade" }
AuthorityConstraints =
PolicySet = {"Can/US-Trade"}
ConstraintSet ={
ChainNameConstraint = "US-Dept-of-Commerce",
CertExplicitPolicy = required }
A.3 Example 3: Use of NextCertConstraints Option
Consider the scenario of Example 2 but, to minimize
administrative complexity, the Canadian government does not
directly certify the "US-Dept-of-Commerce" CA. The two
governments only maintain cross-certificates between their
respective root CAs, which are trusted for all government
business but do not necessarily recognize all identifiable
policies.
The Canadian government root CA could issue a certificate
for the US government root CA with the following extension
fields:
Policies =
PolicySet = {"Can/US-Trade"}
PolicyMappings ={
issuerDomainPolicies = {"Can/US-Trade"}
subjectDomainPolicy = "US/Can-Trade" }
AuthorityConstraints =
PolicySet = {"Can/US-Trade"}
ConstraintSet = {
ChainNameConstraint =
{subtree under "US-Dept-of-Commerce"},
CertExplicitPolicy = notRequired,
NextCertConstraints =
{ CertExplicitPolicy = required }
}
A.4 Example 4: Cross-Certification into Internet RFC1422
Structure
Suppose a commercial organization, ABC Corp., wants to cross-
certify into the RFC1422 infrastructure, recognizing either
of the PCAs "PQR Commercial PCA" and "XYZ Commercial PCA" as
being consistent with the local policy "ABC Commercial
Protection".
Two possible approaches follow. Firstly, the ABC Corp. CA
could issue certificates for each of the PCAs. The
certificate for the "PQR Commercial PCA" CA, for example,
would have the following extension fields:
Policies =
PolicySet = {"ABC Commercial Protection"}
AuthorityConstraints =
PolicySet = {"ABC Commercial Protection"}
ConstraintSet =
{ ChainNameSubordConstraint = subordinateToCA }
Alternatively, if the ABC Corp. preferred to certify the PEM
IPRA's public key, it could issue a certificate for the IPRA
with the following extension fields:
Policies =
PolicySet = {"ABC Commercial Protection"}
AuthorityConstraints =
PolicySet = {"ABC Commercial Protection"}
ConstraintSet = {
CertNameConstraint =
{either of the precise names "PQR
Commercial PCA" or "XYZ Commercial PCA"},
NextCertConstraints =
{ ChainNameSubordConstraint = subordinateToCA
}
}
_______________________________
1 Principles for providing the required protection are
described in the U.S. Department of Defense Trusted Computer
System Evaluation Criteria, DOD 5200.28-STD, 1985. In terms
of these principles, certificate chain processing needs to
be implementable within a Trusted Computing Base (TCB).