Here is text of the Working Draft of proposed X.509 certificate
extensions in ISO.
Warwick Ford
-----------------------------
~7
Certificate Definitions
Source: ISO/IEC JTC1/SC21/WG4, Southampton
1. Scope
This project is developing extensions to the definitions of
certificates and certificate revocation lists (CRLs) in
ISO/IEC 9594-8. These extensions are in the following
areas:
a) extensions to certificates to support indicators of key
usage and key identifier;
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 support policy
identifiers and constraints, with the latter being
applicable to CA-certificates, i.e., certificates for
CAs issued by other CAs;
d) extensions to CRLs to support the capability to
temporarily suspend a certificate, and subsequently
either revoke or reinstate it;
e) extensions to CRLs to better support their use for
nonrepudiation purposes;
f) optional CRL formats to provide for breaking the
revocation information from one CA into multiple parts
for operational purposes.
This Working Draft contains technical proposals for items a)
through d) in clauses 5 through 8, respectively, and
discussion and a call for comments on items e) and f) in
clause 9.
This Working Draft assumes that a certificate extension
field, which provides for indicating
criticality/noncriticality of each extension, has already
been added to the certificate and CRL formats. This Working
Draft defines a set of extensions to be used in conjunction
with that field.
2. Normative References
[no changes]
3. Definitions
CA-certificate A certificate for one CA issued by
another CA
4. Abbreviations
CA Certification Authority
PCMCIA Personal Computer Memory Card
International Association
PEM Privacy Enhanced Mail
TCB Trusted Computing Base
5. Key Usage and Key Identifiers
5.1 Requirements
The following requirements regarding key usage and key
identifiers need to be accommodated:
a) It should be possible to securely associate a public
key with a particular usage, e.g., digital signature,
encryption key transport, encryption key agreement.
Correct usage needs to be checkable by a public-key
user, i.e., certificate user.
b) When a CA issues a certificate for another CA, the
issuing CA may wish to constrain certificates issued by
the subject CA (or subsequently chained certificates)
to ultimately certifying user public keys for limited
usage purposes. (See also clause 7.)
c) It should be possible to positively identify different
public keys for the same user used at different points
in time. Such identification needs to be included in a
public key certificate.
5.2 Certificate Extension Fields
One certificate extension field, called the KeyIdAndUsage
field is defined. It comprises the following two optional
subfields:
a) KeyUsage: This subfield indicates the intended use of
the public key being certified. It is applicable to
both CA-certificates and end-user certificates.
b) KeyIdentifier: This subfield enables distinct keys
used by the same subject to be differentiated (e.g., as
key updating occurs). It is applicable to both CA-
certificates and end-user certificates.
The following ASN.1 type is proposed for use in this
extension field:
KeyIdAndUsage ::= SEQUENCE {
keyUsage KeyUsage OPTIONAL,
keyIdentifier KeyIdentifier OPTIONAL }
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
nonRepudShortTerm (4) -- for digital signature
-- for short-term nonrepudiation
nonRepudLongTerm (5) } -- for digital signature
-- for long-term nonrepudiation
CAKeyUsage ::= BIT STRING {
keyCertSign (0), -- for a CA to sign public key
-- certificates
offLineCRLSign (1), -- for a CA to sign an off-line
-- CRL
onLineCRLSign (2), -- for a CA to sign an on-line
-- CRL
transactionSign (3) } -- for a CA to sign on-line
-- administration transactions
KeyIdentifier ::= BIT STRING
This extension is noncritical.
The KeyUsage subfield serves to distinguish a CA-certificate
from an end-user 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.
6. Secondary Public Keys
6.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.
6.2 Certificate Extension Fields
The certificate extension field, called
SecondaryPublicKeyInfo is defined. This field indicates the
intended use of the public key being certified. It is
applicable to both CA-certificates and end-user
certificates.
The following ASN.1 type is defined for use in this field:
SecondaryPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
keyUsage KeyUsage,
keyIdentifier KeyIdentifier,
secondaryPublicKey BIT STRING }
This extension is noncritical.
7. Policy Identifiers and Constraints
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.
In general, processing of a certificate chain needs to
consider the trust associated with each certificate. If one
homogeneous security 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
CA-certificates are used in certificate chain processing,
which is a high-assurance function required in all public-
key user systems, including digital signature verification
systems and systems which perform public-key-based
encryption. Such functions should be suitable for
implementation in a Trusted Computing Base (TCB);
furthermore, they should be suitable for implementation in
hardware cryptographic modules such as cryptographic PCMCIA
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) It should not be necessary for certificate chain
processing to depend upon real-time interactions with
the local user nor 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.)
c) Maximal policy freedom should be permitted. Any
security domain should be able to stipulate which CAs
in other domains it trusts and for which purposes.
Chaining through multiple policy domains should be
supported.
d) Complete flexibility in trust models is required. A
strict hierarchical model which is adequate for a
single government is not adequate when considering the
needs of governments internationally nor when
considering the needs of non-government enterprises.
e) Key-pair updating, on a regular or exceptional-
condition basis, should not be precluded (or made
unduly difficult) for any CA.
f) Flexibility should be possible in selection of the
first trusted CA in a chain processed by any public-key
user system. In particular, it should be possible to
require that the chain start in the local security
domain of the public-key user system.
g) Naming should not be artificially constrained, i.e.,
X.500 name structures considered natural for
organizations or geographical areas should 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 specified in RFC 1422.
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, multiple policies may be
recognized.
c) Between security domains, relationships may exist to
allow two domains to trust each other with respect to a
particular policy or with respect to different, but
compatible, policies.
d) One domain may not be prepared to fully trust lower-
level CAs in another domain; this leads to a
requirement for constraints on CA behaviour that can be
automatically enforceable.
7.3 Concepts
To satisfy the above requirements, two concepts are
introduced: identified policies and CA constraints. See
Annex A for examples of how these concepts may be used in
practice.
7.3.1 Identified Policies
Identified policies involve the assignment of identifiers to
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 which can be
automatably 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.
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.2 CA Constraints
CA constraints are an "insurance" provision which enables a
chain-verifying system to check 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-user certificates.
b) 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 local-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). This field is applicable to
both CA-certificates and end-user certificates.
The following ASN.1 type is proposed for use in this field:
Policies ::= SET OF PolicyID
PolicyID ::= OBJECT IDENTIFIER
-- policyIDs are registered by community-
interest
-- groups or private organizations
This extension is noncritical.
7.4.2 AuthorityConstraints 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 is proposed for use in this
extension field:
AuthorityConstraints ::= SET OF SEQUENCE {
policyID PolicyID OPTIONAL,
-- If policyID is omitted, constraintSet
-- applies to any policy
constraintSet ConstraintSet }
ConstraintSet ::= SEQUENCE {
certNameConstraint NameConstraint OPTIONAL,
certAlgorithmConstraint AlgorithmConstraint OPTIONAL,
certExplicitPolicy ExplicitPolicy
DEFAULT notRequired,
chainNameConstraint NameConstraint OPTIONAL,
chainAlgorithmConstraint AlgorithmConstraint OPTIONAL,
chainKeyUsageConstraint KeyUsage OPTIONAL,
chainNameSubordConstraint NameSubordConstraint
DEFAULT noConstraint,
chainLenConstraint ChainLenConstraint OPTIONAL,
nextPolicy NextPolicy OPTIONAL,
nextCertConstraints NextCertConstraints OPTIONAL }
NameConstraint ::= SET OF SubtreeClassSpecification
-- SubtreeClassSpecification imported from
-- BasicAccessControl module in X.501 --
AlgorithmConstraint ::= SET 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
NextPolicy ::= PolicyID
NextCertConstraints ::= ConstraintSet
This extension is critical.
Note the convention that 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. 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 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 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.
chainKeyUsageConstraint: If this constraint is
present, the user key certified at the end of this
certificate chain can be considered valid only for the
identified key usages.
chainNameSubordConstraint: 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-
users 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.
nextPolicy: If this field is present, it gives a new
active policy to be used in processing the certificate
issued by the subject of this certificate and in any
subsequent certificates until a new nextPolicy is
specified.
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.
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
userSignature, keyEncryption, dataEncryption, and
keyAgreement.
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 active
policy is set to that specified by the initial active policy
identifier and the explicit-policy indicator is stored.
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-user 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 and dates are valid.
b) Check that the KeyUsage field 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 nextPolicy 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-user certificate
include:
a) Check that the signature verifies and dates are valid.
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. CRL Reason and Suspend Extensions
8.1 Requirements
The following requirements for extending the CRL format need
to be accommodated:
a) It should be possible to convey in a CRL an indication
of the reason for revocation.
b) There is a requirement to be able to temporarily
suspend validity of a certificate and subsequently
either revoke or reinstate it.
NOTE - These requirements have been recognized by the ANSI
committee developing the ANSI X9.30-3 standard on
certificate management, and the CRL format in that standard
has been extended accordingly. It is a goal of this project
to achieve aligned formats for ANSI X9.30-3 and ISO/IEC 9594-
8 CRLs.
8.2 CRL Extension Fields
One CRL entry extension field, called the CRLReasonAndHold
extension, is defined.
The following ASN.1 type is proposed for use in this field:
CRLReasonAndHold ::= SEQUENCE {
reasonCode CRLReason DEFAULT other,
expirationDate UTCTime OPTIONAL,
-- present if reasonCode is certHold
instructionCode HoldInstruction DEFAULT id-none }
CRLReason ::= ENUMERATED {
other (0),
keyCompromise (1),
caCompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
certHoldRelease (7),
... }
HoldInstruction ::= OBJECT IDENTIFIER
This extension is noncritical.
The reason code may be used by applications to decide, based
on local policy, how to react to posted revocations.
The hold option allows a certificate to be placed in a
suspended state. It may later be reinstated by posting a
certHoldRelease entry on a CRL (for one issue cycle only)
then removing the entry from the next CRL issue, thereby
returning the certificate to its original (valid) state.
9. Issues - Other Extensions
Potential requirements have also been raised for:
a) extensions to CRLs to better support their use for
nonrepudiation purposes;
b) optional CRL formats to provide for breaking the
revocation information from one CA into multiple parts
for operational purposes.
National Body comment is invited on the need for extensions
in these areas, and technical proposals are solicited.
Further discussion of these topics follows.
9.1 Non-repudiation Extensions
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. The presence of this optional date
within a CRL entry might be made mandatory when the key of
the certificate is used for a non-repudiation service.
Non-repudiation aside, this date might be useful for other
purposes. For example, suppose a buyer sends a signed order
to a supplier on date x. The supplier is working for a
considerable period on filling the order then receives a
revocation notice for the buyer's certificate. If the
supplier knows that the revocation does not apply to the
original order date (date x), then his reaction will be
different than if it possibly did apply to that date. (For
example, the supplier may decide differently on whether or
not to continue processing the order.)
9.2 CRL Partitioning
The CRL from one CA can become extremely large and, for
reasons of operational practicality and efficiency, it may
be highly desirable to be able to distribute CRL information
in smaller pieces than the complete CRL. Three possible
ways of segmenting CRLs for distribution purposes have been
proposed, each of which is useful in different operational
environments:
a) Segment a CRL into different serial number ranges.
Then, if a certificate user needs to check if the
certificate with serial number n has been revoked, he
need only obtain, validate, and check the CRL segment
covering that serial number. In some operational
environments this may greatly improve efficiency over
having to obtain, validate, and check the complete CRL.
As an alternative to pure number-range matching, other
matching rules might be considered.
b) Distribute CRL information in the form of delta files,
i.e., each (signed) delta file contains the new CRL
entries since the preceding distribution. This mode of
operation is efficient for environments in which CRL
information is maintained in trusted storage at the
certificate-using system.
c) Segment a CRL into separate signed parts on the basis
of revocation reason. For example, there may be
separate CRL parts for compromise revocations, for
routine (e.g., job change, name change, or address
change) revocations, and for "suspend" revocations.
This may make the CRL processing task much more
efficient for certain applications.
The extensions project can potentially provide
specifications supporting any, or all, of the above
partitioning options.
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.)
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
AuthorityConstraints field:
AuthorityConstraints =
PolicyId = "US/Can-Trade"
ConstraintSet =
{ ChainNameConstraint =
{subtree under country=Canada},
ChainAlgorithmConstraint =
"Digital-Signature-Algorithm" }
A.2 Example 2: Cross-Certification with Compatible
Policies
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
AuthorityConstraints field:
AuthorityConstraints =
PolicyId = "Can/US-Trade"
ConstraintSet ={
ChainNameConstraint = "US-Dept-of-Commerce",
CertExplicitPolicy = required,
NextPolicy = "US/Can-Trade"
}
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
AuthorityConstraints field:
AuthorityConstraints =
PolicyId = "Can/US-Trade"
ConstraintSet = {
ChainNameConstraint =
{subtree under "US-Dept-of-Commerce"},
CertExplicitPolicy = notRequired,
NextPolicy = "US/Can-Trade",
NextCertConstraints =
{ CertExplicitPolicy = required }
}
A.4 Example 4: Cross-Certification into 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 AuthorityConstraints field:
AuthorityConstraints =
PolicyId = "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 AuthorityConstraints field:
AuthorityConstraints =
PolicyId = "ABC Commercial Protection"
ConstraintSet = {
CertNameConstraint =
{either of the precise names "PQR
Commercial PCA" or "XYZ Commercial PCA"},
NextCertConstraints =
{ ChainNameSubordConstraint = subordinateToCA
}
}
u
F| V~~z
-
P
E
S
B
k
<
g
#
_
9
f
g
-