Attached is text of the Proposed Draft Amendment (PDAM) on ISO/IEC 9594-8
(ITU-T
Rec. X.509) on standard certificate extensions for use with v3 certificates and
v2 CRLs. This text is about to be issued for 90-day ballot within ISO/IEC
JTC1/SC21.
I encourage readers of this list to review and provide constructive comments on
this text.
Postscript and MS Word versions of this document, and other new X.500
documents,
will be made available on-line by Hoyt Kesterson
(H(_dot_)Kesterson(_at_)az05p(_dot_)bull(_dot_)com).
Annonymous ftp to nc-17.ma02.bull.com directory
pub/Osidirectory/94OrlandoOutput.
Warwick Ford
-------------------
ISO/IEC 9594-8 PDAM 1
Information Technology - Open Systems Interconnection - The Directory:
Authentication Framework
AMENDMENT 1: Certificate Extensions
Introduction
This clause provides an introduction to this amendment. The text in this
clause is not intended for inclusion in ISO/IEC 9594-8.
This amendment specifies extensions to the definitions of certificates
and certificate revocation lists (CRLs) in ITU-T Rec. X.509 | ISO/IEC
9594-8. 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 and certificate policy;
b) extensions to certificates to support certification of other public
keys used for different purposes from the primary public key;
c) extensions to certificates to convey alternative-form names and
additional attribute information about the certificate subject and
issuer;
d) extensions to certificates to allow constraint specifications to be
included in CA-certificates, i.e., certificates for CAs issued by
other CAs, to facilitate the automated processing of certification
paths when multiple certificate policies are involved, e.g., when
policies vary for different applications in an environment or when
interoperation with external environments occurs;
e) CRL extensions to allow a CRL to include indications of revocation
reason, to provide for temporary suspension of a certificate, and
to include CRL-issue sequence numbers to allow certificate users to
detect missing CRLs in the sequence from one CA;
f) certificate and CRL extensions to allow the complete set of
revocation information from one CA to be partitioned into separate
CRLs to facilitate control of CRL sizes, and CRL extensions to
support the use of partial CRLs indicating only changes since the
preceding CRL issue.
3.3 Authentication framework definitions
Add the following at the end of the list:
o) CA-certificate: A certificate for one CA issued by another CA.
p) certificate policy: A named set of policy statements relating to
use of a certificate recognized by both the issuer and user of the
certificate. Typically, different certificate policies will relate
to different applications which use certified keys.
q) end entity: The subject of the final certificate in a
certification path, i.e., that subject which is not a CA.
r) key agreement: A method for negotiating a key value on-line
without transferring the key, even in an encrypted form, e.g., the
Diffie-Hellman technique.
s) policy mapping: Recognizing that, when a CA in one domain
certifies a CA in another domain, a particular certificate 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 certificate policy in the first domain.
4 Abbreviations
Insert the following after the first item:
CRL Certificate revocation list
8 Obtaining a user's public key
Insert the following at the end of the paragraph immediately before the
ASN.1 defining the EXTENSION object class (added by Technical
Corrigendum):
Standard extensions for certificates are defined in clause 12 of this
Directory Specification.
11.2 Management of certificates
Insert the following as a third note after the CRL ASN.1 definition:
3 Standard extensions for CRLs are defined in clause 12 of this
Directory Specification.
Add the following new clause:
12 Certificate extensions
12.1 Introduction
This clause specifies extensions to certificates in the following areas:
a) Key and policy information: These certificate extensions convey
additional information about the subject and issuer keys, such as
key identifiers and indicators of approved key usage. They also
convey indicators of certificate policy. They facilitate the
implementation of public-key infrastructures and allow
administrators to limit the purposes for which certificates and
certified keys are used.
b) Other public key: This certificate extension supports
certification of other public keys used for different purposes from
the primary public key.
c) Subject and issuer attributes: These certificate extensions
support alternative-form names for certificate subject and issuer.
They can also convey additional attribute information about the
subject, to assist a certificate user in being confident that the
certificate subject is a particular person or entity.
d) Certification path constraints: These certificate extensions allow
constraint specifications to be included in CA-certificates, i.e.,
certificates for CAs issued by other CAs, to facilitate the
automated processing of certification paths when multiple
certificate policies are involved, e.g., when policies vary for
different applications in an environment or when interoperation
with external environments occurs. The constraints may restrict
the types of certificates which can be issued by the subject CA or
which may occur subsequently in a certification path.
e) Basic CRL extensions: These CRL extensions allow a CRL to include
indications of revocation reason, to provide for temporary
suspension of a certificate, and to include CRL-issue sequence
numbers to allow certificate users to detect missing CRLs in the
sequence from one CA.
f) CRL distribution points and delta-CRLs: These certificate and CRL
extensions allow the complete set of revocation information from
one CA to be partitioned into separate CRLs, and support the use of
partial CRLs indicating only changes since the preceding CRL issue.
Use of each extension is at the option of the CA issuing a certificate.
In a certificate, an extension is flagged as being either critical or
non-critical. If a critical extension is included in a certificate and
the particular extension field type is not recognized by the certificate-
using system, then that system shall consider the certificate invalid.
If a certificate-using system does not recognize the identifier of a non-
critical extension, it may process the remainder of the certificate
ignoring the extension. Extension definitions indicate if they are
always critical, always non-critical, or if criticality can be decided
by the certificate issuer for an instance of use.
12.2 Key and policy information
12.2.1 Requirements
The following requirements relate to key and policy information:
a) CA key pair updating can occur on a regular cyclic basis or in
special circumstances. This leads to a requirement for a
certificate field to convey an identifier of the public key used to
sign the certificate. The certificate verifier needs to use such
identifiers in finding the correct CA-certificate for validating
the certificate issuer's public key.
b) In general, a certificate subject has different public keys and,
correspondingly, different certificates for different purposes,
e.g., digital signature, encipherment 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.
c) Subject key pair updating can occur on a regular cyclic basis or in
special circumstances. This leads to a requirement for a
certificate field to convey an identifier to distinguish between
different public keys for the same subject used at different points
in time. The public-key user needs to use such identifiers in
finding the correct certificate to use.
d) The private key corresponding to a certified public key is
typically used over a different period from the validity of the
public key. For example, with digital signature keys, the usage
period for the signing private key is typically much shorter than
that for the verifying public key. The validity period of the
certificate indicates a period for which the public key may be
used, which is not necessarily the same as the usage period of the
private 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 to be able to indicate the usage period of the private
key in a certificate.
e) Because certificates may be used in environments where multiple
certificate policies apply, provision must be made for including
certificate policy information in certificates.
f) A CA needs to be able to restrict usage of a certified public key
to a particular purpose or to stipulate that particular policy
rules are to apply to its use.
g) When cross-certifying from one organization to another, it can
sometimes be agreed that certain of the two organizations' policies
can be considered equivalent. This leads to a requirement, in a CA-
certificate, for the certificate issuer to be able to indicate that
one or more of its own certificate policies are equivalent to
another certificate policy in the subject CA's domain. This is
known as policy mapping.
h) A user of an encipherment or digital signature system which uses
certificates defined in this Directory Specification needs to be
able to determine in advance the algorithms supported by other
users.
Notes
1 An example of policy mapping is as follows. 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 certification paths
extending cross-border within the rules implied by these policies for
relevant purposes.
2 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. In
the above example, it would be preferable for the U.S., Canada, and
Mexico to agree upon a common policy for "North American Trade".
3 It is anticipated that policy mapping will be practical only in
limited environments in which policy statements are very simple.
12.2.2 Certificate extension fields
The following certificate extension fields are defined:
a) Authority key identifier: This field enables distinct keys used by
the same certification authority to be differentiated. The key may
be identified by an explicit key identifier, by identification of
a certificate for the key (using certificate issuer name and
certificate serial number), or by both.
b) Primary key attributes: This field provides for 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.
c) Certificate policies: This field lists certificate policies that
the certificate is expressly recognized as supporting, together
with optional qualifier information pertaining to these policies.
d) Primary-key usage restriction: This field indicates a restriction
imposed as to the purposes for which, and policies under which, the
certified public key may be used.
e) Policy mappings: This field, which is for use in CA-certificates
only, allows a certificate issuer to indicate that one or more of
that issuer's certificate policies can be considered equivalent to
another policy used in the subject CA's domain.
All of the above extensions except policy mappings are applicable to
both CA-certificates and end-entity certificates. In addition, a
Directory attribute is defined to support the selection of an algorithm
for use when communicating with a remote end entity using certificates
as defined in this Directory Specification.
12.2.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
IDENTIFIED BY { id-ce 1 } }
AuthorityKeyId ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
certIssuer [1] Name OPTIONAL,
certSerialNumber [2] CertificateSerialNumber OPTIONAL
-- certIssuer and certSerialNumber constitute a logical pair,
-- and if either is present both must be present. Either this
-- pair or the keyIdentifier field shall be present. If all
-- three fields are present, then the certificate issuer
-- shall ensure they are consistent -- }
KeyIdentifier ::= OCTET STRING
This extension is always non-critical. A key identifier must be unique
with respect to all key identifiers for the subject with which it is
used.
12.2.2.2 Primary-key attributes field
This field provides for 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, and/or an indication of the
period of use of the corresponding private key. The following ASN.1
type defines this field:
primaryKeyAttributes EXTENSION ::= {
SYNTAX KeyAttributes
IDENTIFIED BY { id-ce 2 } }
KeyAttributes ::= SEQUENCE {
keyIdentifier KeyIdentifier OPTIONAL,
keyUsage KeyUsage OPTIONAL,
privateKeyUsagePeriod Validity OPTIONAL }
KeyUsage ::= CHOICE {
userKeyUsage [0] UserKeyUsage,
cAKeyUsage [1] CAKeyUsage }
UserKeyUsage ::= BIT STRING {
authentication (0),
integrity (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
nonRepudiation (5) }
CAKeyUsage ::= BIT STRING {
keyCertSign (0),
offLineCRLSign (1),
transactionSign (2) }
This extension is always non-critical.
The keyUsage field indicates the intended purpose of the key, and is for
use in finding the correct key/certificate of a user who has multiple
keys/certificates. It is an advisory field and does not imply that
usage of the key is restricted to the purpose indicated. If use of a
key is to be restricted to a particular purpose, the primary-key usage
restriction extension shall be used. Values of the keyUsage field are
as follows:
a) authentication: for digital signatures for purposes of data origin
authentication or peer-entity authentication;
b) integrity: for digital signatures for integrity purposes;
c) keyEncipherment: for enciphering keys or other security
information;
d) dataEncipherment: for enciphering user data (but not keys or other
security information);
e) keyAgreement: for a key agreement mechanism;
f) nonRepudiation: for digital signatures as part of a nonrepudiation
mechanism;
g) keyCertSign: for a CA to sign certificates;
h) offLineCRLSign: for a CA to sign a CRL for off-line (e.g.,
Directory) distribution;
i) transactionSign: for a CA to sign on-line administration
transactions.
The value in the keyUsage field shall not conflict with the value of the
CA-or-end-entity extension if present in the same certificate.
The privateKeyUsagePeriod field indicates the period of use of the
private key corresponding to the certified public key.
Notes
1 The period of use of the private key may be different from the
period of valid use of the corresponding public key which is indicated
by the certificate validity period. For example, with digital
signature keys, the usage period for the signing private key is
typically much shorter than that for the verifying public key.
2 Using the mechanisms described in this standard, a public key should
only be used for signature verification if a valid certificate still
exists. Signature verification after all certificates for the
verification public key have expired can only be achieved using
additional mechanisms such as secure archival or trusted notary
services.
12.2.2.3 Certificate policies field
This field lists certificate policies that the certificate is expressly
recognized as supporting, together with optional qualifier information
pertaining to these policies.
The following ASN.1 type defines this field:
certificatePolicies EXTENSION ::= {
SYNTAX PolicyInformation
IDENTIFIED BY { id-ce 3 } }
PolicyInformation ::= SEQUENCE OF SEQUENCE {
certPolicyId CERTIFICATE-POLICY.&id,
qualifier CERTIFICATE-POLICY.&Qualifier {(_at_)certPolicyId}
OPTIONAL }
This extension is always non-critical. It does not necessarily
constrain use of the certificate to the policies listed. However, if
the certificate is used in association with one of these policies, the
information in any qualifier specified must apply.
A certificate policy may be defined by any organization with a need.
Object identifiers used to identify certificate policies shall be
assigned in accordance with CCITT Rec. X.660 | ISO/IEC 9834-1. The
following ASN.1 object class is used in defining specific certificate
policies:
CERTIFICATE-POLICY ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL }
WITH SYNTAX {
POLICY-IDENTIFIER &id
[QUALIFIER-TYPE &Qualifier] }
12.2.2.4 Primary-key usage restriction field
This field indicates a restriction imposed as to the purposes for which,
and policies under which, the certified public key may be used. The
following ASN.1 type defines this field:
primaryKeyUsageRestriction EXTENSION ::= {
SYNTAX CertPolicySet
IDENTIFIED BY { id-ce 4 } }
CertPolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= CERTIFICATE-POLICY.&id
This extension is always critical. It indicates that the key shall only
be used for the purpose, and under the policy rules, implied by one of
the certificate policies stated. Typically, different certificate
policies will relate to different applications which may use the
certified key. Qualifiers pertaining to the stated policies may be
conveyed in the certificate policies extension. If the primary key is
for a CA then the restriction also applies to end entity keys certified
by a path which uses the CA's key (subject to policy mapping, if
applicable).
12.2.2.5 Policy mappings field
This field, which is for use in CA-certificates only, allows a
certificate issuer to indicate that one or more of that issuer's
certificate policies can be considered equivalent to another policy used
in the subject CA's domain.
The following ASN.1 type defines this field:
policyMappings EXTENSION ::= {
SYNTAX PolicyMappingSyntax
IDENTIFIED BY { id-ce 5 } }
PolicyMappingSyntax ::= SEQUENCE OF SEQUENCE {
issuerDomainPolicies CertPolicySet,
subjectDomainPolicy CertPolicyId }
This extension is always non-critical.
12.2.2.6 Supported algorithms attribute
A Directory attribute is defined to support the selection of an
algorithm for use when communicating with a remote end entity using
certificates as defined in this Directory Specification. The following
ASN.1 defines this (multi-valued) attribute:
supportedAlgorithms ::= ATTRIBUTE {
WITH SYNTAX SupportedAlgorithm
ID { id-at 52 } }
SupportedAlgorithm ::= SEQUENCE {
algorithm AlgorithmIdentifier,
usage [0] KeyUsage OPTIONAL,
usageRestriction [1] PolicyInformation OPTIONAL }
The value of the usage field provides an indication of the intended
algorithm usage purpose. The value of the usageRestriction field
identifies the certificate policies and, optionally, certificate policy
qualifiers with which the identified algorithm may be used.
12.3 Other public key
12.3.1 Requirements
It should be possible to convey in a certificate more than one public
key for different algorithms or different key usage purposes. For
example, it should be possible for a certificate for a digital signature
key to also carry a key for encryption key agreement.
12.3.2 Certificate extension field
One certificate extension field is defined. It is applicable to both CA-
certificates and end-entity certificates. The following ASN.1 type
defines this field:
otherPublicKey EXTENSION ::= {
SYNTAX OtherPublicKeyInfo
IDENTIFIED BY { id-ce 6 } }
OtherPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
keyUsageRestriction [0] CertPolicySet OPTIONAL,
keyAttributes [1] KeyAttributes OPTIONAL,
otherPublicKey [2] BIT STRING }
This extension is always non-critical. The values of the
keyUsageRestriction and keyAttributes fields are interpreted in a
similar way to those of the primary-key usage restriction and primary-
key attributes extensions, but apply to the other key rather than the
primary key.
This extension shall not be used for conveying a key used for
certificate and/or CRL signing.
12.4 Subject and issuer attributes
12.4.1 Requirements
The following requirements relate to subject and issuer attributes:
a) To facilitate the use of certificates by applications based on
other name forms, including Internet electronic mail names,
Internet DNS names, and X.400 originator/recipient addresses, it is
necessary to be able to securely associate names of such forms with
a certificate subject or a certificate issuer.
b) 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.
12.4.2 Certificate extension fields
The following certificate extension fields are defined:
a) Subject alternative name: This field provides a name, of a name
form other than that of Directory names, which is bound by the CA
to the certified public key.
b) Issuer alternative name: This field provides a name, of a name
form other than that of Directory names, for the certificate
issuer.
c) Subject directory attributes: This field conveys any desired
Directory attribute values for the subject of the certificate.
All of these extensions are applicable to both CA-certificates and end-
entity certificates.
12.4.2.1 Subject alternative name field
This field provides a name, of a name form other than that of Directory
names, which is bound by the CA to the certified public key. The
following ASN.1 type defines this field:
subjectAltName EXTENSION ::= {
SYNTAX AltName
IDENTIFIED BY { id-ce 7 } }
AltName ::= CHOICE {
rfc822Name [0] IA5String,
dNSName [1] IA5String,
x400Address [2] ORAddress -- Imported from X.400 --,
privateName [3] INSTANCE OF PRIVATE-NAME }
PRIVATE-NAME ::= TYPE-IDENTIFIER
This extension is always non-critical. An implementation which
recognizes this extension is not required to be able to process all
alternatives of the choice. If the alternative used is not supported by
the implementation, the extension field is ignored.
Use of the TYPE-IDENTIFIER class is described in Annexes A and C of ITU-
T Rec. X.681 | ISO/IEC 8824-2.
12.4.2.2 Issuer alternative name field
This field provides a name, of a name form other than that of Directory
names, for the certificate issuer. The following ASN.1 type defines
this field:
issuerAltName EXTENSION ::= {
SYNTAX AltName
IDENTIFIED BY { id-ce 8 } }
This extension is always non-critical. An implementation which
recognizes this extension is not required to be able to process all
alternatives of the choice. If the alternative used is not supported by
the implementation, the extension field is ignored.
12.4.2.3 Subject directory attributes field
This field conveys any desired Directory attribute values for the
subject of the certificate. The following ASN.1 type defines this
field:
subjectDirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax
IDENTIFIED BY { id-ce 9 } }
AttributesSyntax ::= SEQUENCE OF Attribute
-- Imported from InformationFramework
This extension is always non-critical.
12.5 Certification path constraints
In general, processing of a certification path needs to consider the
trust associated with each certificate. If one homogeneous certificate
policy applies to all certificates this is not an issue. However, when
multiple security policies are involved (e.g., when policies vary for
different applications in an environment or when interoperation with
external environments occurs) certification path processing requires
additional information to be made available, either from the
certificates themselves or from local sources. The following extensions
provide a means for conveying requisite information within the
certificates themselves.
12.5.1 Requirements
In any public-key user system, including digital signature verification
systems and systems which perform public-key-based encryption,
processing of a certification path is a high-assurance task. The
implementation of the certification path 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 sent. Furthermore, certification path
processing functions should be suitable for implementation in hardware
cryptographic modules such as cryptographic tokens or smart cards.
The following requirements relate to certification path processing:
a) It must be possible to differentiate between an end-entity
certificate and a CA-certificate, to prevent against end-entities
establishing themselves as CAs without authorization. The extent
to which CAs can extend certification paths also need to be
controlled.
b) There is a need for a CA to be able to specify constraints which
allow a certificate user to check that less-trusted CAs in a
certification path (i.e., CAs further down the certification path
from the CA with whose public key the certificate user starts) are
not violating their trust. The most important constraint involves
restricting the name space for which a CA can certify. One example
of such a constraint is the Internet Privacy Enhanced Mail (PEM)
name subordination rule [see Internet RFC 1422]. Adherence to
these constraints must be automatically checkable by the
certificate user.
c) It must be possible to implement certification path processing in
an automated, self-contained module. This is necessary to permit
trusted hardware or software modules to be implemented which
perform the certification path processing functions.
d) Certification path processing must not depend upon real-time
interactions with the local user.
e) Certification path 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 certification path processing but the amount of such
information should be minimized.)
f) Certification paths need to be able to operate in environments in
which multiple certificate policies are recognized. A CA must be
able to stipulate which CAs in other domains it trusts and for
which purposes. Chaining through multiple policy domains must be
supported.
g) 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 multiple interconnected
enterprises. Flexibility is required in selection of the first
trusted CA in a certification path. In particular, it shall be
possible to require that the certification path start in the local
security domain of the public-key user system.
h) Key-pair updating, on a regular or exceptional-condition basis,
shall not be precluded (or made unduly difficult) for any CA.
i) Naming must not be artificially constrained, i.e., Directory name
structures considered natural for organizations or geographical
areas must not need adjustment in order to accommodate
certification authority requirements.
j) Certificate extension fields need to be backward-compatible with
the unconstrained certification path approach system as specified
in 1988 and 1993 editions of ITU-T Rec. X.509 | ISO/IEC 9594-8 and
with the Internet Privacy Enhanced Mail constraints [see Internet
RFC 1422].
k) There must be support for relationships between domains which allow
two domains to trust each other with respect to a particular
certificate policy or with respect to different, but compatible,
certificate policies.
12.5.2 Certificate extension fields
The following certificate extension fields are defined:
a) CA-or-end-entity indicator: This field indicates whether the
certified subject may act as a CA, an end-entity, or both.
b) Name constraints: This field specifies a set of constraints with
respect to the names for which subsequent CAs in a certification
path may issue certificates.
c) Policy constraints: This field specifies a set of constraints with
respect to explicit certificate policy identification and end-
entity key usage restrictions.
The name constraints and policy constraints extensions are applicable to
CA-certificates only. Examples of the use of these extensions are given
in Annex L.
12.5.2.1 CA-or-end-entity indicator field
This field indicates whether the certified subject may act as a CA, an
end-entity, or both. If the subject may act as a CA, a certification
path length constraint may also be specified. The following ASN.1 type
defines this field:
cAorEndEntityIndicator EXTENSION ::= {
SYNTAX CAorEndEntitySyntax
IDENTIFIED BY { id-ce 10 } }
CAorEndEntitySyntax ::= SEQUENCE {
subjectType SubjectType,
pathLenConstraint INTEGER OPTIONAL }
SubjectType ::= BIT STRING {
cA (0),
endEntity (1) }
This extension may, at the option of the certificate issuer, be either
critical or non-critical.
The value of the subjectType field is interpreted as follows:
- if the cA bit is set, the subject may act as a CA;
- if the endEntity bit is set, the subject may act as an end
entity.
The pathLenConstraint field is meaningful only if cA is set. It gives
the maximum number of CA-certificates that may follow this certificate
in a certification path. Value 0 indicates that the subject of this
certificate may issue certificates only to end-entities and not to
further CAs. If no pathLenConstraint field appears in any certificate
of a certification path, there is no limit to the allowed length of the
certification path.
12.5.2.2 Name constraints field
This field specifies a set of constraints with respect to the names for
which subsequent CAs in a certification path may issue certificates.
The following ASN.1 type defines this field:
nameConstraints EXTENSION ::= {
SYNTAX NameConstraintsSyntax
IDENTIFIED BY { id-ce 11 } }
NameConstraintsSyntax ::= SEQUENCE OF SEQUENCE {
policySet [0] CertPolicySet OPTIONAL,
-- If policySet is omitted, the constraints
-- apply to all policies for which the
-- certificate is applicable
nameSpaceConstraint [1] NameSpaceConstraint OPTIONAL,
nameSubordConstraint [2] NameSubordConstraint OPTIONAL }
NameSpaceConstraint ::= SEQUENCE OF SubtreeSpecification
-- specificationFilter is not permitted
NameSubordConstraint ::= SEQUENCE {
subordType ENUMERATED {
subordinateToCA (0),
subordinateToCAsSuperior (1) }
DEFAULT subordinateToCA,
skipCerts INTEGER DEFAULT 0 }
The constraint fields are interpreted as follows:
- nameSpaceConstraint: If this constraint is present, a certificate
issued by the subject CA of this certificate should only be
considered valid if for a subject within one of the specified
subtrees. Any subtree class specification may contain a chop
specification; if there is no chop specification, a subtree is
considered to extend to the leaves of the DIT.
- nameSubordConstraint: This constraint is associated with a
nominated CA in the certification path, being either the subject CA
of this certificate or a CA which is the subject of a subsequent
certificate in the certification path. If the value
subordinateToCA is specified then, in all certificates in the
certification path starting from a certificate issued by the
nominated CA, 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 certification path starting from a certificate issued by the
nominated CA, the subject name must be subordinate to the name of
the immediately superior DIT node of the issuer of the same
certificate. The value of skipCerts indicates the number of
certificates in the certification path to skip before the name
subordination constraint takes effect; if value 0, the constraint
starts to apply with certificates issued by the subject CA of this
certificate.
12.5.2.3 Policy constraints field
This field specifies constraints which may require explicit certificate
policy identification or inhibit policy mapping for the remainder of the
certification path. The following ASN.1 type defines this field:
policyConstraints EXTENSION ::= {
SYNTAX PolicyConstraintsSyntax
IDENTIFIED BY { id-ce 12 } }
PolicyConstraintsSyntax ::= SEQUENCE OF SEQUENCE {
policySet [0] CertPolicySet OPTIONAL,
-- If policySet is omitted, the
constraints
-- apply to all policies for which the
-- certificate is applicable
requireExplicitPolicy [1] SkipCerts OPTIONAL,
inhibitPolicyMapping [2] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER
The constraint fields are interpreted as follows:
- requireExplicitPolicy: If this field is present it indicates that,
in all certificates starting from a nominated CA in the
certification path until the end of the certification path, it is
necessary for the certificate to contain, in the certificate
policies extension, an acceptable policy identifier. An acceptable
policy identifier is the identifier of the certificate policy
required by the user of the certification path, or the identifier
of a policy which has been declared equivalent to it through policy
mapping. The nominated CA is either the subject CA of the
certificate containing this extension (if the value of SkipCerts is
0) or a CA which is the subject of a subsequent certificate in the
certification path (as indicated by the value of SkipCerts).
- inhibitPolicyMapping: If this field is present it indicates that,
in all certificates starting from a nominated CA in the
certification path until the end of the certification path, policy
mapping is not permitted. The nominated CA is either the subject
CA of the certificate containing this extension (if the value of
SkipCerts is 0) or a CA which is the subject of a subsequent
certificate in the certification path (as indicated by the value of
SkipCerts).
The value of SkipCerts indicates the number of certificates in the
certification path to skip before the constraint becomes effective.
12.5.3 Certification path processing procedure
Certification path processing is carried out in a system which needs to
use the public key of a remote end entity, e.g., a system which is
verifying a digital signature generated by a remote person or entity.
The name constraints, policy constraints, and CA-or-end-entity indicator
extensions have been designed to facilitate automated, self-contained
implementation of certification path processing logic.
Following is an outline of a procedure for validating certification
paths. An implementation shall be functionally equivalent to the
external behaviour resulting from this procedure. The algorithm used by
a particular implementation to derive the correct output(s) from the
given inputs is not standardized.
The inputs to the certification path processing procedure are:
a) a set of certificates comprising a certification path;
b) a CA name and trusted public key value, or an identifier of such a
key (if the key is stored internally to the certification path
processing module), for use in verifying the first certificate in
the certification path;
c) an initial-policy identifier, which identifies the certificate
policy under which the certificate path processing is to occur;
d) an initial-explicit-policy indicator value, which indicates if an
acceptable policy identifier needs to explicitly appear in the
certificate policies extension field of all certificates in the
path; and
e) an initial-policy-mapping-inhibit indicator value, which indicates
if policy mapping is forbidden in the certification path;
f) the current date/time (if not available internally to the
certification path processing module).
The values of c), d), and e) will depend upon the policy requirements of
the user-application combination which needs to use the certified end-
entity public key.
The outputs of the procedure are:
a) an indication of success or failure of certification path
validation;
b) if validation failed, a diagnostic code indicating the reason for
failure;
c) if validation was successful, a (possibly empty) set of policy
qualifiers obtained from CAs on the path.
The procedure makes use of the following set of state variables:
a) acceptable policy set: A set of certificate policy identifiers
comprising the policy requested by the public key user together
with policies deemed equivalent through policy mapping;
b) constrained name space: A set of subtree class specifications
within which the next subject name must fall, or may take the value
unbounded;
c) name-subordination indicator: Indicates which of the following is
in force: no-name-subordination, subordinate-to-CAs-superior, or
subordinate-to-CA;
d) explicit-policy indicator: Indicates if an acceptable policy needs
to be explicitly identified in every certificate;
e) policy-mapping-inhibit indicator: Indicates if policy mapping is
inhibited;
f) pending-constraints: Details of name-subordination, explicit-
policy, and/or inhibit-policy-mapping constraints which have been
stipulated but are yet to take effect. There are four one-bit
indicators called subordinate-to-CA-pending, subordinate-to-CAs-
superior-pending, explicit-policy-pending, and policy-mapping-
inhibit-pending together with, for each, an integer called skip-
certificates which gives the number of certificates yet to skip
before the constraint takes effect.
The procedure involves an initialization step, followed by a series of
certificate-processing steps. The initialization step comprises:
a) Initialize the name-subordination indicator to no-name-
subordination and the constrained name space to unbounded;
b) Initialize the acceptable policy set to the value of the initial-
policy identifier;
c) Initialize the explicit-policy indicator to the initial-explicit-
policy value;
d) Initialize the policy-mapping-inhibit indicator to the initial-
policy-mapping-inhibit value;
e) Initialize the four pending-constraints indicators to unset.
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.
The following checks are applied to all certificates:
a) Check that the signature verifies, that dates are valid, that the
subject and issuer names chain correctly, and that the certificate
has not been revoked.
b) If the CA-or-end-entity indicator extension field is present in the
certificate:
- For a CA-certificate, check that the subject may act as a CA. If
a path length constraint is present, check that the current
certification path does not violate that constraint.
- For an end-entity certificate, check that the subject may act as
an end-entity.
c) If the explicit-policy indicator is set, check that at least one
member of the acceptable policy set appears in the certificate
policies field.
d) For every key usage restriction field present in the certificate
(in a primary key usage restriction extension or recognized other
public key extension), check that at least one member of the
acceptable policy set appears in the field.
e) Check that the subject name is consistent with the constrained name
space.
f) If the name-subordination indicator is not set to no-name-
subordination, check that the subject name is consistent with the
name subordination rule in force.
If any of the above checks fails, the procedure terminates, returning a
failure indication and an appropriate reason code. If none of the above
checks fails on the end-entity certificate, the procedure terminates,
returning a success indication together with the set of all policy
qualifier values encountered in the set of certificates.
For a CA-certificate, the following constraint recording actions are
then performed, in order to correctly set up the state variables for the
processing of the next certificate:
a) If nameSpaceConstraint is present in the certificate, set the
constrained name space to the value indicated in the
nameSpaceConstraint field. Otherwise, set the constrained name
space to unbounded.
b) If the name subordination indicator is not set to subordinate-to-
CA:
- If the subordinate-to-CAs-superior-pending indicator is set,
decrement the corresponding skip-certificates value. If this
value becomes zero, unset the subordinate-to-CAs-superior-pending
indicator and set the name-subordination indicator to subordinate-
to-CAs-superior.
- If the subordinate-to-CA-pending indicator is set, decrement the
corresponding skip-certificates value. If this value becomes
zero, set the name-subordination indicator to subordinate-to-CA
and skip the remaining sub-bulleted items in this bullet b).
- If nameSubordConstraint is present in the certificate with a
SkipCerts value of 0, set the name-subordination indicator to
either subordinate-to-CA or subordinate-to-CAs-superior as
indicated by the subordType field in the certificate.
- If nameSubordConstraint is present in the certificate with a
SkipCerts value greater than 0 and a subordType field indicating
subordinate-to-CA, perform the following. Set the subordinate-to-
CA-pending indicator and set the corresponding skip-certificates
value to the lesser of the SkipCerts value and the previous skip-
certificates value (if the subordinate-to-CA-pending indicator
was already set).
- If nameSubordConstraint is present in the certificate with a
SkipCerts value greater than 0 and a subordType field indicating
subordinate-to-CAs-superior, perform the following. Set the
subordinate-to-CAs-superior-pending indicator and set the
corresponding skip-certificates value to the lesser of the
SkipCerts value and the previous skip-certificates value (if the
subordinate-to-CAs-superior-pending indicator was already set).
c) If the explicit-policy indicator is not set:
- if the explicit-policy-pending indicator is set, decrement the
corresponding skip-certificates value and, if this value becomes
zero, set the explicit-policy indicator.
- If the requireExplicitPolicy constraint is present in the
certificate perform the following. For a SkipCerts value of 0,
set the explicit-policy indicator. For any other SkipCerts
value, set the explicit-policy-pending indicator, and set the
corresponding skip-certificates value to the lesser of the
SkipCerts value and the previous skip-certificates value (if the
explicit-policy-pending indicator was already set).
d) If the policy-mapping-inhibit indicator is not set:
- process any policy mapping extension and add appropriate policy
identifiers to the acceptable policy set.
- if the policy-mapping-inhibit-pending indicator is set, decrement
the corresponding skip-certificates value and, if this value
becomes zero, set the policy-mapping-inhibit indicator.
- If the inhibitPolicyMapping constraint is present in the
certificate perform the following. For a SkipCerts value of 0,
set the policy-mapping-inhibit indicator. For any other
SkipCerts value, set the policy-mapping-inhibit-pending
indicator, and set the corresponding skip-certificates value to
the lesser of the SkipCerts value and the previous skip-
certificates value (if the policy-mapping-inhibit-pending
indicator was already set).
Note - It is possible to specify an extended version of the above
certification path processing procedure which results in default
behaviour identical to the rules of Internet Privacy Enhanced Mail
[see Internet 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
certification path 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 certification path and processing
continues. If no valid PCA name is found, and if the certification
path cannot be validated on the basis of identified policies, then the
certification path is considered invalid.
12.6 Basic CRL extensions
12.6.1 Requirements
The following requirements relate to CRLs:
a) There is a requirement for CRLs from the same CA to convey a
sequence number, so that certificate users wishing to track all
CRLs issued can detect a missing CRL in the sequence.
b) Some CRL users may wish to respond differently to a revocation,
depending upon the reason for the revocation. There is therefore a
requirement for a CRL entry to indicate the reason for revocation.
c) There is a requirement to be able to temporarily suspend validity
of a certificate and subsequently either revoke or reinstate it. A
CA may place a temporary hold on a certificate without permanently
revoking it. Possible reasons for such an action include:
- desire to reduce liability for erroneous revocation when a
revocation request is unauthenticated and there is inadequate
information to determine whether it is valid;
- other business needs, such as temporarily disabling the
certificate of an entity pending an audit or investigation, etc.
d) A revocation certificate contains, for each revoked certificate,
the date when revocation occurred. This date is insufficient to
solve some disputes because, assuming the worst, all signatures
issued during the validity period of the certificate have to be
considered invalid. However, in a commercial environment, it may
be important for a user that a signed document is recognized as
valid even in the case where the key used to sign the message has
been lost. The presence of another date within the user
certificate can assist in solving this problem - the date when the
user was still sure that his key was not compromised. All
signatures issued by the user before this date will be recognized
by the user as valid.
12.6.2 CRL and CRL entry extension fields
The following CRL extension field is defined:
a) CRL number: This CRL extension field conveys a monotonically
increasing sequence number for each CRL issued by a given CA.
The following CRL entry extension fields are defined:
a) Reason code: This CRL entry extension field identifies a reason
for the certificate revocation.
b) Expiration date: This CRL entry extension field indicates the
expiration date of a hold entry in a CRL. It is required for a
hold reason code and inapplicable otherwise.
c) Instruction code: This CRL entry extension field provides for
inclusion of a registered instruction identifier to indicate the
action to be taken on encountering a held certificate. It is
required for a hold reason code and inapplicable otherwise.
d) Known good date: This CRL entry extension field indicates a date
at which a key which has been revoked for compromise reasons was
known to still be good.
12.6.2.1 CRL number field
This CRL extension field conveys a monotonically increasing sequence
number for each CRL issued by a given CA. The following ASN.1 defines
this field:
cRLNumber EXTENSION ::= {
SYNTAX INTEGER
IDENTIFIED BY { id-ce 20 } }
This extension is always non-critical. It allows a CRL user to detect
when a CRL was issued prior to the next scheduled update indicated in
the nextUpdate field of the last received CRL.
12.6.2.2 Reason code field
This CRL entry extension field identifies a reason for the certificate
revocation. The reason code may be used by applications to decide,
based on local policy, how to react to posted revocations. The
following ASN.1 defines this field:
reasonCode EXTENSION ::= {
SYNTAX CRLReason
IDENTIFIED BY { id-ce 21 } }
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
caCompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
certHoldRelease (7),
removeFromCRL (8) }
This extension is always non-critical.
The certificateHold and certHoldRelease options are used as follows:
- A certificate may be placed on hold by issuing a CRL entry with a
reason code of certificateHold. The certificate hold notice must
include the date and time at which it is scheduled to expire. It
may also include an optional hold instruction code to convey
additional information to subscribers.
- The scheduled duration will vary according to the purpose of the
hold. In the case of an unauthenticated revocation request, where
the CA is unsure of the identity of the requester, the hold might
last for a few days, or even a few hours, as needed to investigate
and verify the authenticity of the request. If a substantial
enterprise must be placed on hold, the CA will wish to complete its
investigation as quickly as possible. Holds issued for other
business purposes might specify a longer time.
- A certificate hold shall remain on the CRL until the expiration of
the underlying certificate or the expiration of the hold, whichever
is later. Once a hold has been issued, it may be handled in one of
four ways:
a)remain on the CRL with no further action, causing users to reject
transactions issued during the hold period (i.e., after the
original action and prior to the natural expiration of the hold);
b)be updated with a new expiration date farther in the future, if
additional time is needed to resolve the matters for which the
hold was issued, in which case transactions issued during the
entire period shall continue to be rejected;
c)be replaced by a (final) revocation for the same certificate,
effective as of the original action date of the hold, in which
case the reason shall be one of the standard reasons for
revocation, and the optional fields will not appear, or
d)be explicitly released, by means of an updated entry with a
reason code of certHoldRelease, keeping the original action date,
but with the expiration date set to the date of the release.
The removeFromCRL reason code is for use with delta-CRLs only to
indicate an existing CRL entry should now be removed owing to
certificate expiration.
12.6.2.3 Hold expiration date field
This CRL entry extension field indicates the expiration date of a hold
entry in a CRL. It is required for a certificateHold reason code and
inapplicable otherwise. The following ASN.1 defines this field:
expirationDate EXTENSION ::= {
SYNTAX UTCTime
IDENTIFIED BY { id-ce 22 } }
This extension is always non-critical.
12.6.2.4 Hold instruction code field
This CRL entry extension field provides for inclusion of a registered
instruction identifier to indicate the action to be taken on
encountering a held certificate. It is required for a certificateHold
reason code and inapplicable otherwise. The following ASN.1 defines
this field:
instructionCode EXTENSION ::= {
SYNTAX HoldInstruction
IDENTIFIED BY { id-ce 23 } }
HoldInstruction ::= OBJECT IDENTIFIER
This extension is always non-critical. No standard hold instruction
codes are defined in this Directory Specification.
12.6.2.5 Invalidity date field
This CRL entry extension field indicates the date at which the condition
which caused the revocation occurred (e.g., the date of suspected key
compromise). This date may be earlier than the revocation date in the
CRL entry, which is the date at which the CA processed the revocation.
The following ASN.1 defines this field:
invalidityDate EXTENSION ::= {
SYNTAX GeneralizedTime
IDENTIFIED BY { id-ce 24 } }
This extension is always non-critical.
Note - When a revocation is first posted by a CA in a CRL, the
invalidity date may precede the date of issue of earlier CRLs. The
revocation date should not precede the date of issue of earlier CRLs.
12.7 CRL distribution points and delta-CRLs
12.7.1 Requirements
As it is possible for revocation lists to become large and unwieldy,
forms to represent partial CRLs are required. There are two major types
of implementations that process CRLs. The first is on high performance
servers where a large volume of messages is processed, e.g., a
transaction processing server. In this environment CRLs are typically
processed as a background task where, after the CRL is validated, the
contents of the CRL are stored locally in a representation which
expedites their examination, e.g., one bit for each certificate
indicating if it has been revoked. This representation is held in
trusted storage. This type of server will typically require up-to-date
CRLs for a large number of CAs. Since it already has a list of
previously revoked certificates, it only needs to retrieve a list of
newly revoked certificates. This list, called a delta-CRL, will be
smaller and require fewer resources to retrieve and process than a
complete CRL.
The second type of implementation is in individual workstations,
possibly in an attached cryptographic token. These implementations are
likely to have limited, if any, trusted storage capacity. Therefore the
entire CRL must be examined to determine if it is valid, and then to see
if the certificate is valid. This processing could be lengthy if the
CRL is long. Partitioning of CRLs is required to eliminate this problem
for these implementations.
The following requirements therefore relate to CRL distribution points
and delta-CRLs:
a) In order to control CRL sizes, it must be possible to assign
subsets of the set of all certificates issued by one CA to
different CRLs. This can be achieved by associating every
certificate with a CRL Distribution Point which is a Directory
entry whose CRL attribute will contain a revocation entry for that
certificate, if it has been revoked.
b) There is a requirement for separate CRLs covering revoked CA-
certificates and revoked end-entity certificates. This facilitates
processing of certification paths as the the CRL for revoked CA-
certificates can be expected to be very short (usually empty). The
authorityRevocationList and certificateRevocationList attributes
have been specified for this purpose. However, for this separation
to be secure, it is necessary to have an indicator in a CRL
identifying which list it is. Otherwise, illegitimate substitution
of one for the other cannot be detected.
c) Provision is needed for a different CRL to exist for potential
compromise situations (when there is a significant risk of private
key misuse) than that including all routine binding terminations
(when there is no significant risk of private key misuse).
d) Provision is also needed for partial CRLs (known as delta-CRLs)
which only contain the identities of certificates that have been
revoked since the last update.
e) In satisfying requirements a), b), c), and d), provision should be
made to accommodate, as an alternative or supplementary CRL
distribution mechanism, the default approach of a CA issuing its
own CRL for all certificates it issues.
12.7.2 Certificate extension fields
One certificate extension field is defined. This field identifies the
CRL Distribution Point or Points to which a certificate user should
refer to ascertain if the certificate has been revoked. One
distribution point is identified to contain certificate revocation
indications, regardless of revocation reason. Optionally, one or more
additional distribution points may be identified as containing
revocation entries for a limited set of revocation reasons. A
certificate user should obtain and use the CRL from the applicable
distribution point, unless it can obtain a current complete CRL from
the CA itself.
The following ASN.1 type defines this field:
cRLDistributionPoints EXTENSION ::= {
SYNTAX CRLDistPointsSyntax
IDENTIFIED BY { id-ce 25 } }
CRLDistPointsSyntax ::= SEQUENCE OF DistributionPoint
-- There must be at least one member of this SEQUENCE. The first
-- member must have the reasons component absent, and the list
-- distributed from this point must contain all revocations
-- regardless of revocation reason
DistributionPoint ::= SEQUENCE {
distributionPoint Name,
reasons ReasonFlags OPTIONAL }
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
caCompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6) }
This extension is non-critical. If a certificate user does not
recognize this field, then that user should only accept the certificate
if it can acquire and check a complete CRL from the CA; that the latter
CRL is complete is indicated by the absence of an issuing distribution
point extension field in the CRL.
12.7.3 CRL extension fields
The following CRL extension fields are defined:
a) Issuing distribution point: This field identifies the CRL
distribution point for this particular CRL, and indicates if the
CRL is limited to revocations for user certificates only, for CA-
certificates only, or for a limited set of reasons only.
b) Delta CRL indicator: This field identifies a CRL as being a delta-
CRL only.
12.7.3.1 Issuing distribution point field
This CRL extension field identifies the CRL distribution point for this
particular CRL, and indicates if the CRL is limited to revocations for
end-entity certificates only, for CA-certificates only, or for a limited
set of reasons only. The CRL is signed by the CA's key - CRL
Distribution Points do not have their own key pairs. However, the CRL
is stored in the directory entry corresponding to the CRL distribution
point, which may not be the directory entry of the CA. The following
ASN.1 type defines this field:
issuingDistributionPoint EXTENSION ::= {
SYNTAX IssuingDistPointSyntax
IDENTIFIED BY { id-ce 26 } }
IssuingDistPointSyntax ::= SEQUENCE {
distributionPoint [0] Name OPTIONAL,
-- If name absent, CRL must contain all revocations
-- by the CA consistent with the qualifiers below
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL
-- If absent, contains all revocations regardless of reason--
}
This extension is always critical. A certificate user which does not
understand the use of CRL distribution points should not use a CRL
containing this extension, as the CRL may not be as complete as the user
expects. CRLs not containing critical extensions must contain all
current CRL entries for the issuing CA, including entries for all
revoked user certificates and CA certificates, and may be used by users
which do or do not not understand the use of this extension.
12.7.3.2 Delta CRL indicator field
This CRL extension field identifies a CRL as being a delta-CRL only.
The following ASN.1 defines this field:
deltaCRLIndicator EXTENSION ::= {
SYNTAX BaseCRLNumber
IDENTIFIED BY { id-ce 27 } }
BaseCRLNumber ::= INTEGER
This extension is always critical. A certificate user who does not
understand the use of delta-CRLs should not use a CRL containing this
extension, as the CRL may not be as complete as the user expects. CRLs
not containing critical extensions must contain all current CRL entries
for the issuing CA, including entries for all revoked user certificates
and CA certificates, and may be used by users who do or do not
understand the use of this extension.
The value of BaseCRLNumber identifies the CRL number of the base CRL
assumed as the starting point in the generation of this delta-CRL.
After applying the changes indicated in this delta-CRL to the base CRL,
the result will be a CRL with a CRL number the same as that given in the
CRL number extension of this delta-CRL
12.7.4 Attribute type for delta-CRLs
The following attribute type is defined for holding a delta-CRL in a CA
directory entry:
deltaRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
ID {id-at 53 } }
This completes the new clause 12.
Annex A: Authentication Framework in ASN.1
Change the introductory paragraph to:
This annex includes all of the ASN.1 type, value, and information object
class definitions contained in this Directory Specification, in the form
of the two ASN.1 modules AuthenticationFramework and
CertificateExtensions.
At the end of the annex, add the following:
CertificateExtensions {joint-iso-ccitt ds(5) module(1)
certificateExtensions(26) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
id-at, id-ce, informationFramework, authenticationFramework
FROM UsefulDefinitions {joint-iso-ccitt ds(5) module(1)
usefulDefinitions(0) 2}
Name, ATTRIBUTE, Attribute, SubtreeSpecification
FROM InformationFramework informationFramework
CertificateSerialNumber, CertificateList, Validity,
AlgorithmIdentifier, EXTENSION
FROM AuthenticationFramework authenticationFramework
ORAddress
FROM MTSAbstractService {joint-iso-ccitt mhs-motis(6)
mts(3) modules(0) mts-abstract-service(1) } ;
-- Key and policy information extensions --
authorityKeyIdentifier EXTENSION ::= {
SYNTAX AuthorityKeyId
IDENTIFIED BY { id-ce 1 } }
AuthorityKeyId ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
certIssuer [1] Name OPTIONAL,
certSerialNumber [2] CertificateSerialNumber OPTIONAL
-- certIssuer and certSerialNumber constitute a logical pair,
-- and if either is present both must be present. Either this
-- pair or the keyIdentifier field shall be present. If all
-- three fields are present, then the certificate issuer
-- shall ensure they are consistent -- }
KeyIdentifier ::= OCTET STRING
SubjectType ::= BIT STRING {
cA (0),
endEntity (1) }
primaryKeyAttributes EXTENSION ::= {
SYNTAX KeyAttributes
IDENTIFIED BY { id-ce 2 } }
KeyAttributes ::= SEQUENCE {
keyIdentifier KeyIdentifier OPTIONAL,
keyUsage KeyUsage OPTIONAL,
privateKeyUsagePeriod Validity OPTIONAL }
KeyUsage ::= CHOICE {
userKeyUsage [0] UserKeyUsage,
cAKeyUsage [1] CAKeyUsage }
UserKeyUsage ::= BIT STRING {
authentication (0),
integrity (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
nonRepudiation (5) }
CAKeyUsage ::= BIT STRING {
keyCertSign (0),
offLineCRLSign (1),
transactionSign (2) }
certificatePolicies EXTENSION ::= {
SYNTAX PolicyInformation
IDENTIFIED BY { id-ce 3 } }
PolicyInformation ::= SEQUENCE OF SEQUENCE {
certPolicyId CERTIFICATE-POLICY.&id,
qualifier CERTIFICATE-POLICY.&Qualifier {(_at_)certPolicyId}
OPTIONAL }
CERTIFICATE-POLICY ::= CLASS {
&id OBJECT IDENTIFIER UNIQUE,
&Qualifier OPTIONAL }
WITH SYNTAX {
POLICY-IDENTIFIER &id
[QUALIFIER-TYPE &Qualifier] }
primaryKeyUsageRestriction EXTENSION ::= {
SYNTAX CertPolicySet
IDENTIFIED BY { id-ce 4 } }
CertPolicySet ::= SEQUENCE OF CertPolicyId
CertPolicyId ::= CERTIFICATE-POLICY.&id
policyMappings EXTENSION ::= {
SYNTAX PolicyMappingSyntax
IDENTIFIED BY { id-ce 5 } }
PolicyMappingSyntax ::= SEQUENCE OF SEQUENCE {
issuerDomainPolicies CertPolicySet,
subjectDomainPolicy CertPolicyId }
supportedAlgorithms ::= ATTRIBUTE {
WITH SYNTAX SupportedAlgorithm
ID { id-at 52 } }
SupportedAlgorithm ::= SEQUENCE {
algorithm AlgorithmIdentifier,
usage [0] KeyUsage OPTIONAL,
usageRestriction [1] PolicyInformation OPTIONAL }
-- Other public key extension --
otherPublicKey EXTENSION ::= {
SYNTAX OtherPublicKeyInfo
IDENTIFIED BY { id-ce 6 } }
OtherPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
keyUsageRestriction [0] CertPolicySet OPTIONAL,
keyAttributes [1] KeyAttributes OPTIONAL,
otherPublicKey [2] BIT STRING }
-- Subject and issuer attributes extensions --
subjectAltName EXTENSION ::= {
SYNTAX AltName
IDENTIFIED BY { id-ce 7 } }
AltName ::= CHOICE {
rfc822Name [0] IA5String,
dNSName [1] IA5String,
x400Address [2] ORAddress,
privateName [3] INSTANCE OF PRIVATE-NAME }
PRIVATE-NAME ::= TYPE-IDENTIFIER
issuerAltName EXTENSION ::= {
SYNTAX AltName
IDENTIFIED BY { id-ce 8 } }
subjectDirectoryAttributes EXTENSION ::= {
SYNTAX AttributesSyntax
IDENTIFIED BY { id-ce 9 } }
AttributesSyntax ::= SEQUENCE OF Attribute
-- Imported from InformationFramework
-- Certification path constraints extensions --
cAorEndEntityIndicator EXTENSION ::= {
SYNTAX CAorEndEntitySyntax
IDENTIFIED BY { id-ce 10 } }
CAorEndEntitySyntax ::= SEQUENCE {
subjectType SubjectType,
pathLenConstraint INTEGER OPTIONAL }
nameConstraints EXTENSION ::= {
SYNTAX NameConstraintsSyntax
IDENTIFIED BY { id-ce 11 } }
NameConstraintsSyntax ::= SEQUENCE OF SEQUENCE {
policySet [0] CertPolicySet OPTIONAL,
-- If policySet is omitted, the constraints
-- apply to all policies for which the
-- certificate is applicable
nameSpaceConstraint [1] NameSpaceConstraint OPTIONAL,
nameSubordConstraint [2] NameSubordConstraint OPTIONAL }
NameSpaceConstraint ::= SEQUENCE OF SubtreeSpecification
-- specificationFilter is not permitted
NameSubordConstraint ::= SEQUENCE {
subordType ENUMERATED {
subordinateToCA (0),
subordinateToCAsSuperior (1) }
DEFAULT subordinateToCA,
skipCerts INTEGER DEFAULT 0 }
policyConstraints EXTENSION ::= {
SYNTAX PolicyConstraintsSyntax
IDENTIFIED BY { id-ce 12 } }
PolicyConstraintsSyntax ::= SEQUENCE OF SEQUENCE {
policySet [0] CertPolicySet OPTIONAL,
-- If policySet is omitted, the
constraints
-- apply to all policies for which the
-- certificate is applicable
requireExplicitPolicy [1] SkipCerts OPTIONAL,
inhibitPolicyMapping [2] SkipCerts OPTIONAL }
SkipCerts ::= INTEGER
-- Basic CRL extensions --
cRLNumber EXTENSION ::= {
SYNTAX INTEGER
IDENTIFIED BY { id-ce 20 } }
reasonCode EXTENSION ::= {
SYNTAX CRLReason
IDENTIFIED BY { id-ce 21 } }
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
caCompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
certHoldRelease (7),
removeFromCRL (8) }
expirationDate EXTENSION ::= {
SYNTAX UTCTime
IDENTIFIED BY { id-ce 22 } }
instructionCode EXTENSION ::= {
SYNTAX HoldInstruction
IDENTIFIED BY { id-ce 23 } }
HoldInstruction ::= OBJECT IDENTIFIER
invalidityDate EXTENSION ::= {
SYNTAX GeneralizedTime
IDENTIFIED BY { id-ce 24 } }
-- CRL distribution points and delta-CRL extensions --
cRLDistributionPoints EXTENSION ::= {
SYNTAX CRLDistPointsSyntax
IDENTIFIED BY { id-ce 25 } }
CRLDistPointsSyntax ::= SEQUENCE OF DistributionPoint
-- There must be at least one member of this SEQUENCE. The first
-- member must have the reasons component absent, and the list
-- distributed from this point must contain all revocations
-- regardless of revocation reason
DistributionPoint ::= SEQUENCE {
distributionPoint Name,
reasons ReasonFlags OPTIONAL }
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
caCompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6) }
issuingDistributionPoint EXTENSION ::= {
SYNTAX IssuingDistPointSyntax
IDENTIFIED BY { id-ce 26 } }
IssuingDistPointSyntax ::= SEQUENCE {
distributionPoint [0] Name OPTIONAL,
-- If name absent, CRL must contain all revocations
-- by the CA consistent with the qualifiers below
onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,
onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,
onlySomeReasons [3] ReasonFlags OPTIONAL
-- If absent, contains all revocations regardless of reason--
}
deltaCRLIndicator EXTENSION ::= {
SYNTAX BaseCRLNumber
IDENTIFIED BY { id-ce 27 } }
BaseCRLNumber ::= INTEGER
deltaRevocationList ATTRIBUTE ::= {
WITH SYNTAX CertificateList
ID {id-at 53 } }
-- Object identifier assignments --
id-at-supportedAlgorithms OBJECT IDENTIFIER ::= {id-at 52}
id-at-deltaRevocationList OBJECT IDENTIFIER ::= {id-at 53}
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= {id-ce 1}
id-ce-primaryKeyAttributes OBJECT IDENTIFIER ::= {id-ce 2}
id-ce-certificatePolicies OBJECT IDENTIFIER ::= {id-ce 3}
id-ce-primaryKeyUsageRestriction OBJECT IDENTIFIER ::= {id-ce 4}
id-ce-policyMappings OBJECT IDENTIFIER ::= {id-ce 5}
id-ce-otherPublicKey OBJECT IDENTIFIER ::= {id-ce 6}
id-ce-subjectAltName OBJECT IDENTIFIER ::= {id-ce 7}
id-ce-issuerAltName OBJECT IDENTIFIER ::= {id-ce 8}
id-ce-subjectDirectoryAttributes OBJECT IDENTIFIER ::= {id-ce 9}
id-ce-cAorEndEntityIndicator OBJECT IDENTIFIER ::= {id-ce 10}
id-ce-nameConstraints OBJECT IDENTIFIER ::= {id-ce 11}
id-ce-policyConstraints OBJECT IDENTIFIER ::= {id-ce 12}
id-ce-cRLNumber OBJECT IDENTIFIER ::= {id-ce 20}
id-ce-reasonCode OBJECT IDENTIFIER ::= {id-ce 21}
id-ce-expirationDate OBJECT IDENTIFIER ::= {id-ce 22}
id-ce-instructionCode OBJECT IDENTIFIER ::= {id-ce 23}
id-ce-invalidityDate OBJECT IDENTIFIER ::= {id-ce 24}
id-ce-cRLDistributionPoints OBJECT IDENTIFIER ::= {id-ce 25}
id-ce-issuingDistributionPoint OBJECT IDENTIFIER ::= {id-ce 26}
id-ce-deltaCRLIndicator OBJECT IDENTIFIER ::= {id-ce 27}
END
Add a new Annex K as follows:
Annex K: Bibliography
(This annex does not form an integral part of this Recommendation |
International Standard)
D.H. Crocker, "Standard for the Format of ARPA Internet Text Messages",
RFC 822, Internet Activities Board, 1982.
S. Kent, "Privacy Enhancement for Internet Electronic Mail, Part II:
Certificate-Based Key Management", RFC 1422, Internet Activities Board,
1993.
Add a new Annex L as follows:
Annex L: Examples of use of certification path constraints
(This annex does not form an integral part of this Recommendation |
International Standard)
L.1 Example 1: Use of name space and path length constraints
Suppose the Widget Corporation wants to cross-certify the central CA of
the Acme Corporate Group, constraining that CA to only issue
certificates for end-entities within the DIT subtrees {Country=US,
Org=Acme Inc} and {Country=UK, Org=Acme Ltd}. No chaining through
further CAs is permitted.
The Widget Corporation could satisfy these requirements by issuing a
certificate for Acme's central CA, including the following extension
field values:
Value of CA-or-end-entity Indicator Field:
{ subjectType cA, pathLenConstraint 0 }
Value of Name Constraints Field:
{{ nameSpaceConstraint
{ -- subtree specification under the DIT node
-- {Country=US, Org=Acme Inc} --,
-- subtree specification under the DIT node
-- {Country=UK, Org=Acme Ltd} -- }} }}
L.2 Example 2: Use of name space and name subordination constraints
Suppose the Widget Corporation wants to cross-certify the central CA of
the Acme Corporate Group, constraining that CA to only issue
certificates for end-entities or subordinate CAs within the DIT subtrees
{Country=US, Org=Acme Inc} and {Country=UK, Org=Acme Ltd}. Furthermore,
if a subordinate Acme CA is certified, its certificates will only be
recognized by Widget if they are for subjects whose names are
subordinate to that CA's DIT-superior node; for example, if the CA
named {Country=US, Org=Acme Inc, Org Unit=Marketing, Common Name=Acme
Marketing Cert Authority} is certified, its certificates will only be
considered valid if they are for subjects within the name space
subordinate to {Country=US, Org=Acme Inc, Org Unit=Marketing}.
The Widget Corporation could satisfy these requirements by issuing a
certificate for Acme's central CA, including the following extension
field value:
Value of Name Constraints Field:
{{ nameSpaceConstraint
{ -- subtree specification under the DIT node
-- {Country=US, Org=Acme Inc} --,
-- subtree specification under the DIT node
-- {Country=UK, Org=Acme Ltd} -- }},
nameSubordConstraint { subordType subordinateToCAsSuperior,
skipCerts 1 } }}
L.3 Example 3: Cross-certification into Internet RFC 1422 structure
Suppose a commercial organization, ABC Corp., wants to cross-certify
into the RFC 1422 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
directly issue certificates for each of the two PCAs. Such certificates
would have the following extension field values:
Value of Certificate Policies Field:
{{ -- OID for ABC Commercial Protection -- }}
Value of Name Constraints Field:
{{ nameSubordConstraint { subordType subordinateToCA, skipCerts 1 }
}}
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 field values:
Value of Certificate Policies Field:
{{ -- OID for ABC Commercial Protection -- }}
Value of Name Constraints Field:
{{ nameSpaceConstraint
{ -- subtree specification giving only the single
-- name "PQR Commercial PCA" --,
-- subtree specification giving only the single
-- name "XYZ Commercial PCA"}},
nameSubordConstraint { subordType subordinateToCA, skipCerts 2 } }}
L.4 Example 4: Policy mapping and policy constraints
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 U.S. government
signatures with respect to a Canadian policy called "Can/US-Trade";
b) the U.S. government has a policy called "US/Can-Trade", which the
Canadian government is prepared to consider equivalent to its
"Can/US-Trade" policy;
c) the Canadian government wants to apply safeguards which require all
U.S. certificates to explicitly state support for the policy and
which inhibit mapping to other policies within the U.S. domain.
A Canadian government CA could issue a certificate for a U.S. government
CA with the following extension field values:
Value of Certificate Policies Field:
{{ -- OID for "Can/US-Trade" -- }}
Value of Policy Mappings Field:
{{ issuerDomainPolicies { -- OID for "Can/US-Trade" -- },
subjectDomainPolicy -- OID for "US/Can-Trade -- }}
Value of PolicyConstraints Field:
{ policySet { -- OID for "Can/US-Trade" -- }, requireExplicitPolicy
(0), inhibitPolicyMapping (0)}