Ar
c
hi
ve
d
Gatekeeper PKI Framework
February 2009
X.509 Certificate
and
Certificate Revocation List Profiles
ve
d
hi
Ar
c
Department of Finance and Deregulation
Australian Government Information Management Office
© Commonwealth of Australia 2009
This work is copyright. Apart from any use as permitted under the Copyright Act 1968, no part may be reproduced by any
process without prior written permission from the Commonwealth.
Requests and inquiries concerning reproduction and rights should be addressed to the Commonwealth Copyright
Administration, Attorney-General’s Department, Robert Garran Offices, National Circuit, Barton ACT 2600 or posted at
http://www.ag.gov.au/cca
2
X.509 Certificate and CRL Profiles
February 2009
CONTENTS
3.
Background..................................................................................................................4
1.2
Scope ............................................................................................................................5
1.3
References....................................................................................................................5
1.4
Definitions ...................................................................................................................6
1.5
Acronyms and abbreviations .....................................................................................7
1.6
Conformance ...............................................................................................................8
1.7
Document structure ...................................................................................................8
ve
d
1.1
CERTIFICATE PROFILE............................................................................................................8
2.1
General.........................................................................................................................8
2.2
Certificate fields ..........................................................................................................9
2.3
Certificate extensions...............................................................................................11
hi
2.
INTRODUCTION ....................................................................................................................4
CRL PROFILE .........................................................................................................................16
Ar
c
1.
3.1
CRL fields ....................................................................................................................16
3.2
CRL extensions...........................................................................................................17
3.3
CRL entry extensions.................................................................................................18
APPENDIX A : PROFILE SUMMARIES ...........................................................................................20
A1
Required Capability...................................................................................................20
APPENDIX B : DIVERGENCE FROM AS4539.1.2.1 (2001) .............................................................23
B1
General.......................................................................................................................23
B2
Certificate Profile Differences..................................................................................23
B3
CRL Profile Differences..............................................................................................26
3
X.509 Certificate and CRL Profiles
February 2009
1. INTRODUCTION
1.1
Background
The Australian Government’s vision is to make greater use of Information and Communications
Technology (ICT) to enable a transformation of the business of government. A critical element of
enabling electronic service delivery is having the means to authenticate and secure online Transactions.
Choice of service models will be available but increasingly individuals and businesses are choosing to
utilise electronic authentication to participate in electronic Transactions.
Simplified sign-on procedures to access connected government services in an environment of privacy and
security may reduce the cost and complexity of interacting with government.
ve
d
One of the initiatives taken by Government to achieve this vision has been the development of a revised
Gatekeeper Framework for the use of PKI by citizens and business in their interactions with government.
The Framework:
Facilitates the deployment of a broader range of digital certificates designed to meet specific
business requirements of agencies and their clients.
•
Facilitates adoption of a risk management approach aligned to the National e-Authentication
Framework (NeAF) and Government Security Standards.
•
Facilitates increased use of PKI by both business and the broader community through reducing
the cost and complexity of producing, acquiring and using digital certificates.
•
Fosters a competitive market for digital certificates.
Ar
c
hi
•
A copy of the Framework can be found at: http://www.gatekeeper.gov.au
The Framework comprises three certificate categories – Special, General and High Assurance for
individuals and businesses. These categories are broadly aligned to the four levels of risk in the NeAF
which can be found at http://www.finance.gov.au/e-government/security-andauthentication/authentication-framework.html.
The Framework is characterised by flexibility in Evidence of Identity (EOI) requirements and the ability of
Relying Parties to readily distinguish between EOI models and EOI assurance levels within those models.
All certificates issued under the Framework will be X.5091 compliant and will be issued by Gatekeeper
Accredited / Recognised Certification Authorities (CAs) or Gatekeeper accredited Registration Authority
Extended Services (RAES).
1
X.509 is an International Telecommunication Union Telecommunication Standardization Sector (ITU-T) standard for Public Key
Infrastructure (PKI). X.509 specifies, amongst other things, standard formats for public key certificates and a certification path validation
algorithm.
4
X.509 Certificate and CRL Profiles
February 2009
Based on risk assessments, agencies will select the type of certificates appropriate for their clients to use
in conducting online Transactions.
1.2
Scope
This document provides a recommended profile for Certificates and Certificate Revocation Lists issued by
Gatekeeper Accredited/Recognised Certification Authorities (CAs). Implementation guidance is provided
for CAs and certificate processing entities.
Conformance with, or divergence from AS4539.1.2.1-2001 (Information Technology – PKAF – General) is
documented for each certificate field. Where appropriate, reasons for making a particular
recommendation are also provided.
References
AS 4539
Australian Standard AS 4539
AS4539.
1.2.12001
ve
d
Information technology—Public Key Authentication Framework
(PKAF)
Information Technology—Public Key Authentication Framework
(PKAF) Part 1.2.1: General – X.509 Certificate and Certificate
Revocation Lists (CRL) profile
hi
AS4539.1 Information Technology—Public Key Authentication Framework
.2.2-2001 (PKAF) Part 1.2.2: General—PICs Proforma For Digital Signature
Certificates
Ar
c
1.3
AS4539.1 Information Technology—Public Key Authentication Framework
.2.3-2001 (PKAF) Part 1.2.3: General—PICS Proforma for
Certificate Revocation Lists (CRL)
AS
4539.1.31999
Information Technology - Public Key Authentication Framework
(PKAF) - General - X.509 supported algorithms profile
GS-1998
Gatekeeper A strategy for public key technology use in the
Government Office of Government Information Technology, The
Commonwealth of Australia, 6 May 1998. ISBN 0 642 32032 2
MP 59 –
2000
Naming and addressing in the Australian OSI environment,
RFC
2459
IETF RFC 2459
Standards Australia miscellaneous publication, Third edition, 2000.
Internet X.509 Public Key Infrastructure Certificate and CRL Profile
5
X.509 Certificate and CRL Profiles
February 2009
RFC
2560
IETF RFC 2560
X.509 Internet Public key Infrastructure Online Certificate Status
Protocol - OCSP
X.509
ITU-T Recommendation X.509 | ISO/IEC 9594-8:
Information Technology – Open Systems Interconnection – The
Directory: Public Key and Attribute Certificate Frameworks.
Definitions
A certificate issued to a Gatekeeper accredited Certification
Authority that is part of the PKAF.
Conforming
application
An application that can process conforming certificates and
CRLs, and may process other certificates or CRLs.
Conforming CA
A CA that issues conforming certificates and CRLs.
Conforming CA
certificate
A CA or External Domain certificate that conforms to this
profile.
Conforming
certificate
A certificate that conforms to this profile.
Conforming CRL
A Certification Revocation List that conforms to this profile.
EE certificate
A certificate issued by a Gatekeeper accredited CA to an End
Entity (EE).
hi
ve
d
CA certificate
Ar
c
1.4
External domain
certificate
A certificate issued to a CA outside of the PKAF, but which is
considered useable by applications within the PKAF.
Gatekeeper
Policy
Committee
The Committee established by the Department of Finance
and Deregulation (Finance) to provide a forum for the
discussion, development and endorsement of
recommendations to the Gatekeeper Competent Authority
for policy and administrative changes to the Gatekeeper
accreditation and recognition programs.
6
X.509 Certificate and CRL Profiles
February 2009
An entity responsible for approval of policy and monitoring
compliance for a PKAF.
Within the Gatekeeper infrastructure, the Policy Approval
Authority is the General Manager, Australian Government
Information Management Office, acting on the
recommendations of the Gatekeeper Policy Committee.
Policy Creation
Authority
An entity delegated by a Policy Approving Authority (PAA)
for the creation of certificate policy(ies) as part of a
hierarchical implementation of a PKAF.
Acronyms and abbreviations
Australian Government Information Management Office
ASN.1
Abstract Syntax Notation One
CA
Certification Authority
CRL
Certificate Revocation List
DN
Distinguished Name
EE
End Entity (i.e. Subscriber – either individual or organisation))
EOI
Evidence Of Identity
GPC
IETF
ISO
hi
ve
d
AGIMO
Ar
c
1.5
Policy Approval
Authority
Gatekeeper Policy Committee
Internet Engineering Task Force
International Organization for Standardization
OID
Object Identifier
PAA
Policy Approval Authority
PCA
Policy Creation Authority
PKAF
Public Key Authentication Framework
RFC
Request For Comment
SHA-1
Secure Hash Algorithm
7
X.509 Certificate and CRL Profiles
February 2009
1.6 Conformance
An implementation conforming to this profile shall also conform to AS4539.1.2.1-2001.
1.7 Document structure
This document follows a similar structure to that of AS4539.1.2.1-2001 on which it is based.
• Section 2 describes the recommended Gatekeeper Certificate Profile2.
• Section 3 describes the recommended Gatekeeper CRL profile.
• Appendix A provides a summary of the requirements for the inclusion of elements in conforming
certificates and CRLs, and required processing for conforming applications.
• Appendix B describes where this profile differs from the recommendations of AS4539.1.2.1-2001, for
2. CERTIFICATE PROFILE
2.1 General
ve
d
each field in the certificate and CRL.
hi
All certificate fields must conform to AS4539.1.2.1-2001. However, this document imposes further
restrictions and interpretations on some fields.
Ar
c
If the recommendation for a field remains unchanged from the standard, this is indicated by a
reference to the standard at the end of the clause describing the field. If no reference is provided, the
field diverges from the draft standard and a description of this divergence is provided in Appendix B.
The recommendations for some fields include additional recommendations to those of the standard.
In these cases, this is indicated by prefixing the additional recommendations with “In addition”.
Unless otherwise specified, the recommendations of this certificate profile shall apply to all
conforming certificates (i.e. CA, EE).
2
Note that under the Gatekeeper PKI Framework scope exists for the development of a range of Supplementary Certificates and also for
the issuance of tailored certificates within the Special Category for operation within defined Communities of Interest. Accordingly,
this document will only apply to certificates issued within the General and High Assurance categories of the Framework.
8
X.509 Certificate and CRL Profiles
February 2009
2.2
2.2.1
Certificate fields
Version
The version generated by conforming CAs shall be V3 as all certificates in this profile contain at least one
extension. Conforming applications shall accept V3 certificates and should accept V1 and V2 certificates.
[AS4539.1.2.1-2001.
[Note that ASN.1 notation starts from zero, so V3 has a value of 2].
2.2.2
Serial number
serialNumber is an integer assigned by the CA to each certificate.
2.2.3
Signature
ve
d
The value of serialNumber shall be unique for each certificate issued by a given CA (ie. the issuer (CA)
name and serial number shall identify a unique certificate). The value of serialNumber should be a
positive integer. [AS4539.1.2.1-2001]
signature identifies the algorithm identifier for the algorithm used by the CA to sign the certificate.
hi
The signature field shall be identical to the algorithmIdentifier field of the SIGNATURE macro defined
in X.509. The algorithms used should be identified using the OIDs and syntax given in Part 1.3: General –
X.509 supported algorithms profile.
Ar
c
Where signature algorithm parameters are required, they shall be included in PAA and External Domain
certificates. They shall be included in other conforming certificates if the subject’s parameters differ from
the certificate issuer’s, or if the issuer uses a different signing algorithm.
If the signature parameters are absent they shall be determined from the certificate issuer’s signature
parameters. [AS4539.1.2.1-2001]
In addition:
Certificates conforming to this profile must support specific encryption and hashing algorithms
depending on the purpose of the certificate (authentication certificate or confidentiality certificate). The
algorithms which must be supported are published independently of this profile at
www.gatekeeper.gov.au and also in ISM at www.dsd.gov.au.
2.2.4
Issuer
issuer identifies the entity (ie CA) that has signed and issued the certificate.
The issuer field shall contain a non-empty Distinguished Name (DN) conforming to Clause 4.1.2.4 of
RFC2459. [AS4539.1.2.1-2001]
9
X.509 Certificate and CRL Profiles
February 2009
The structure of the Issuer’s DN shall conform to MP 59 – 2000.
2.2.5
Validity
validity is the time interval during which the CA warrants that it will maintain information about the
status of the certificate.
Conforming certificates shall encode certificate validity times as specified in Clause 4.1.2.5 of RFC2459.
[AS4539.1.2.1-2001]
Clause 4.1.2.5 of the RFC specifies:
The field is represented as a sequence of two dates: the date on which the certificate validity
period begins (notBefore) and the date on which the certificate validity period ends (notAfter).
Both notBefore and notAfter may be encoded as UTCTime or GeneralizedTime.
●
CAs conforming to this profile MUST always encode certificate validity dates through the year
2049 as UTCTime; certificate validity dates in 2050 or later MUST be encoded as
GeneralizedTime.
2.2.6
ve
d
●
Subject
subject identifies the entity associated with the public-key found in the subject public key field.
hi
The subject field shall contain a Distinguished Name (DN) conforming to Clause 4.1.2.6 of RFC2459.
[AS4539.1.2.1-2001]
2.2.7
Ar
c
The structure of the Subject’s DN shall conform with MP 59 – 2000.
Subject public key info
subjectPublicKeyInfo is used to carry the subject’s public key and identify the algorithm with which
the key is used.
For PAA and External Domain certificates, the sub-field algorithmIdentifier shall include the
algorithm parameters when required by the algorithm.
Conforming certificates shall use the public key algorithms published at at www.gatekeeper.gov.au
and also in ISM at www.dsd.gov.au.
2.2.8
Unique identifiers
The issuerUniqueIdentifier and subjectUniqueIdentifier extensions are used to uniquely identify
issuers and subjects in the case of name re-use.
Conforming certificates shall not contain these unique identifiers. Conforming applications should be
capable of processing these unique identifiers. [AS4539.1.2.1-2001]
10
X.509 Certificate and CRL Profiles
February 2009
2.3
2.3.1
Certificate extensions
General
A certificate extension consists of an extension identifier in the form of an OID, a criticality flag, and a
canonical encoding of a data value of the ASN.1 type associated with the identified extension.
AS4539.1.2.1-2001 defines a number of standard certificate extensions for use within PKAF certificates,
and also allows private extensions to be defined and used by communities to carry information unique
to their purposes.
2.3.2
Standard extensions
2.3.2.1
Authority key identifier
ve
d
In accordance with AS4539.1.2.1-2001 there should be no more than one instance of any particular
certificate extension in a certificate. Conforming applications shall recognise all standard extensions in
this profile that may be marked critical, and should recognise other non-critical extensions defined in
this profile. Conforming applications shall reject a certificate if they encounter a critically marked but
unrecognised certificate extension. An unrecognised certificate extension may be ignored if it is marked
non-critical.
hi
The authorityKeyIdentifier extension identifies the public key to be used to verify the signature in this
certificate. It enables distinct keys used by the same CA to be distinguished (eg. as key updating occurs).
2.3.2.2
Ar
c
Conforming certificates shall identify the key in the keyIdentifier field in the certificate extension. The
value of the keyIdentifier field should be 64 bits OCTET STRING. This is constructed by the 60 least
significant bits of a SHA-1 hash of the DER-encoding of the subjectPublicKeyInfo of the signing CA’s
certificate, prefixed by the hexadecimal value of 0x4 (0100 in binary). This extension shall be present in
EE, CA, PCA and External Domain certificates, and shall not be marked critical. [AS4539.1.2.1-2001]
Subject key identifier
The subjectKeyIdentifier extension identifies the public key being certified. It enables distinct keys used
by the same subject to be differentiated (e.g. as key updating occurs).
Conforming certificates shall identify the key using the keyIdentifier field as described in Clause 4.2.1.2
of RFC2459. The subject key identifier shall be identical to the authority key identifier extension in any
certificates issued by a CA using the identified public key.
This extension shall be present in all conforming certificates, and shall not be marked critical.
[AS4539.1.2.1-2001]
2.3.2.3
Key usage
The keyUsage extension defines the purpose (e.g. encipherment, signature, certificate signing) of the key
contained in the certificate. Recommendations for key usage are contained within AS 4539.1.3.
11
X.509 Certificate and CRL Profiles
February 2009
This extension shall be included in EE certificates, and should be included in PCA, CA and External
Domain certificates. It should only be included in PAA certificates where the PAA has multiple signature
certificates, each for a different purpose. Conforming applications shall use this extension to constrain
the keying material in the certificate to a specific purpose. The extension should be marked critical.
[AS4539.1.2.1-2001]
2.3.2.4
Certificate policies
The certificatePolicies extension contains one or more of the policy information terms, each of which
consists of an OID and optional qualifiers. These policy information terms indicate the policy under
which the certificates have been issued and the purposes for which the certificates may be used.
2.3.2.5
ve
d
This extension shall be present in PCA, CA, EE and External Domain certificates. Optional qualifiers may
be present, however, these qualifiers should be restricted to those defined in Clause 4.2.1.5 of RFC2459.
This extension is optional in PAA certificates, because to limit the subordinate authorities, the PAA need
only include the extension in the subordinate authority’s certificate. Conforming applications with
specific policy requirements shall have a list of those policies that they will accept. The extension may or
may not be marked critical. [AS4539.1.2.1-2001]
Policy mappings
hi
The policyMappings extension allows a certificate issuer to indicate that, for the purposes of the user of
a certification path containing this certificate, one of the issuer’s certificate policies can be considered
equivalent to a different certificate policy used in the subject CA’s domain.
2.3.2.6
Ar
c
This extension shall be included in External Domain certificates, but shall not be included in EE
certificates. It may be included in PAA, PCA or CA certificates. Conforming applications shall support this
extension. The extension shall not be marked critical. [AS4539.1.2.1-2001]
Subject alternative name
The subjectAltName extension contains one or more alternative names, using any of a variety of name
forms, for the entity that is bound by the CA to the certified public key. If present, alternative names
should be considered just as binding as the subject DN.
Conforming certificates that include the subjectAltName extension shall also conform to the
requirements in Clause 4.2.1.7 of RFC2459.
This extension may be present in any conforming certificate. The extension shall not be marked critical.
2.3.2.7
Issuer alternative name
The issuerAltName extension contains one or more alternative names, using any of a variety of name
forms, for the certificate issuer.
12
X.509 Certificate and CRL Profiles
February 2009
Conforming certificates that include the issuerAltName extension shall also conform to the
requirements in Clause 4.2.1.7 of RFC2459.
This extension may be present in any conforming certificate. The extension shall not be marked critical
[AS4539.1.2.1-2001].
2.3.2.8
Subject directory attributes
The subjectDirectoryAttributes extension conveys any desired Directory attribute values for the subject
of the certificate.
It may be present in any conforming certificate. The extension shall not be marked critical. [AS4539.1.2.12001]
2.3.2.9
Basic constraints
ve
d
The precise purpose of this extension is somewhat ambiguous, so caution is recommended if it is used, in
order to avoid incompatibilities with applications.
hi
The basicConstraints extension indicates if the subject may act as a CA, with the certified public key
being used to verify certificate signatures. If so, an optional path length constraint field can be specified
to indicate the maximum number of CA certificates that may follow this certificate in the certification
path. For example, a value of zero indicates that the CA can only issue EE certificates. If there is no path
length constraint, it indicates that there is no restriction on the length of the certification path.
2.3.2.10
Ar
c
This extension should be included in PAA certificates and shall be included in PCA, CA and External
Domain certificates with the cA field set to the value TRUE. Where it appears the pathLenConstraint
field shall be greater than or equal to zero. This extension should not be included in EE certificates. If the
extension is included PCA, CA and External Domain certificates it shall be marked critical. If the extension
is set in a PAA certificate it shall be marked non-critical. [AS4539.1.2.1-2001]
Name constraints
The nameConstraints extension, which shall be used only in a CA certificate, indicates a name space
within which all subject names in subsequent certificates in a certification path shall be located.
Conforming certificates that include the nameConstraints extension shall conform to the requirements
in Clause 4.2.1.11 of RFC2459.
This extension may be present in PAA, PCA, CA and External Domain certificates. It shall not be present in
EE Certificates. If present, the extension shall be marked critical. [AS4539.1.2.3-2001]
2.3.2.11
Policy constraints
The policyConstraints extension specifies constraints that may require explicit certificate policy
identification or inhibit policy mapping for the remainder of the certification path.
13
X.509 Certificate and CRL Profiles
February 2009
Conforming certificates that include the policyConstraints extension shall also conform to the
requirements in Clause 4.2.1.12 of RFC2459. [AS4539.1.2.1-2001]
This extension shall be included in PAA certificates with the requireExplicitPolicy field set to zero,
requiring each subsequent certificate in a chain to include policy identifier. It may be included in any
other conforming CA certificate. It shall be processed by any conforming application. The extension may
be marked critical.
2.3.2.12
CRL distribution points
The cRLDistributionPoints extension identifies how CRL information should be obtained.
Conforming certificates that include the cRLDistributionPoints extension shall also conform to the
requirements in Clause 4.2.1.14 of RFC2459.
2.3.2.13
ve
d
This extension may be included in any conforming certificate. It should be processed by any conforming
application. The extension should not be marked critical. [AS4539.1.2.1-2001]
Extended key usage
The extKeyUsage extension indicates one or more purposes for which the certified public key may be
used, in addition to or in place of the basic purposes indicated in the key usage extension field.
Private key usage period
Ar
c
2.3.2.14
hi
This extension may be included in any conforming certificate. It should be processed by conforming
applications. The extension shall be marked non-critical.
The privateKeyUsagePeriod extension allows the certificate issuer to specify a different validity period
for the Private Key than the certificate. The extension is intended for use with digital signature keys.
This extension consists of two optional components, notBefore and notAfter. The private key
associated with the certificate should not be used to sign objects before or after the times specified by
the two components, respectively. [RFC 2459]
Where used, notBefore and notAfter are represented as GeneralizedTime and shall be specified and
interpreted as defined in section 4.1.2.5.2 of RFC 2459.
The use of this extension is not recommended, but conforming certificates may include the extension if
the certificate is intended for use with digital signature keys. It should be processed by conforming
applications. If this extension is present, the notBefore and notAfter fields within the extension must
be specified. The extension shall not be marked critical.
14
X.509 Certificate and CRL Profiles
February 2009
2.3.3
Other certificate extensions
2.3.3.1
Authority information access
The authority information access extension indicates how to access CA information and services for the
issuer of a certificate. Information and services may include on-line validation services (i.e. through an
Online Certificate Status Protocol (OCSP) transponder) and CA policy data.
Conforming certificates that include the authority information access extension shall also conform to
the requirements in Clause 4.2.2.1 of RFC2459.
This extension may be included in any conforming certificate. It shall not be marked critical.
[AS4539.1.2.1-2001]
2.3.4
Future standard extensions
2.3.4.1
Inhibit any policy
ve
d
This section identifies some of the possible new future standard extensions that are specified in X.509
and recent IETF draft PKIX profiles. These extensions may eventually be included as part of the PKIX
certificate profile.
hi
The inhibitAnyPolicy extension conveys policy information that is similar in purpose to the
policyConstraints extension. It further defines the way a PKI user may interpret the issuing CA’s
policies.
Ar
c
This extension indicates that the special anypolicy OID is not considered to be an explicit match for other
certificate policies for all certificates in the certification path starting with a nominated CA [X.509].
If this extension is present, it shall be marked critical. Conforming applications should support and
process this certificate extension.
2.3.4.2
Freshest CRL (delta CRL distribution point)
The freshestCRL extension indicates how the delta CRL information can be obtained. It has the same
syntax as the cRLDistributionPoint extension.
Since the purpose and syntax for delta CRL Distribution point is similar to the cRLDistributionPoint
extension, it should have the same requirements. Specifically, this extension may be included in any
conforming certificate. It should be processed by conforming applications. The extension shall be
marked non-critical.
15
X.509 Certificate and CRL Profiles
February 2009
3.
3.1
3.1.1
CRL PROFILE
CRL fields
Version
version is the version of the encoded revocation list.
Conforming CAs shall generate CRLs with the version field set to V2 as all CRLs in this profile contain at
least one extension. Conforming applications shall process V2 CRLs.
3.1.2
Signature
signature identifies the algorithm used by the CA to sign the revocation list.
ve
d
The signature field shall be identical to the algorithmIdentifier field of the SIGNATURE macro defined
in X.509. The algorithms used should be identified using the OIDs and syntax given in Part 1.3: General –
X.509 supported algorithms profile.
3.1.3
Issuer name
hi
The parameters sub-field of the CRL signature field should not be used to pass signature algorithm
parameters; rather these parameters should be obtained from the subjectPublicKeyInfo field of the CRL
issuer’s certificate. [AS4539.1.2.1-2001]
Ar
c
issuer identifies the entity (eg CA) that has signed and issued the revocation list.
The issuer field shall contain a non-empty Distinguished Name (DN) conforming to Clause 4.1.2.4 of
RFC2459. [AS4539.1.2.1-2001]
3.1.4
This update
thisUpdate is the date/time that this CRL was issued.
Conforming CRLs shall encode times for the thisUpdate field as specified in Clause 4.1.2.5 of RFC2459.
[AS4539.1.2.1-2001]
3.1.5
Next update
nextUpdate indicates the time by which the next revocation list in this series will be issued. The next
revocation list could be issued before the indicated date, but it will not be issued any later.
Conforming CRLs shall encode times for the nextUpdate field as specified in Clause 4.1.2.5 of RFC2459.
This field shall be included in all conforming CRLs. [AS4539.1.2.1-2001]
16
X.509 Certificate and CRL Profiles
February 2009
3.1.6
Revoked certificates
revokedCertificates identifies certificates that have been revoked. The revoked certificates are named
by their serial numbers.
The time for the revocationDate sub-field shall be encoded as specified in Clause 4.1.2.5 of RFC2459.
If there are no unexpired, revoked certificates, this field may be empty; otherwise conforming CRLs shall
include this element. [AS4539.1.2.1-2001]
3.2
CRL extensions
3.2.1
General
3.2.2
ve
d
Conforming applications shall recognise all extensions listed in this profile that may appear in
conforming CRLs, and that may be marked critical. Conforming applications should recognise other noncritical extensions listed in this profile that may appear in conforming certificates.
Authority key identifier
The authorityKeyIdentifier extension identifies the public key to be used to verify the signature in this
CRL. It enables distinct keys used by the same CRL issuer to be distinguished (e.g. as key updating occurs).
hi
The value for the authorityKeyIdentifier field shall be generated in accordance with the clause for
standard certificate extension authorityKeyIdentifier.
3.2.3
Ar
c
This extension shall be included in all conforming CRLs. It shall not be marked critical. [AS4539.1.2.1-2001]
Issuer alternative name
The issuerAltName extension contains one or more alternative names, using any of a variety of name
forms, for the certificate issuer.
Conforming certificates that include the issuerAltName extension shall also conform to the
requirements in Clause 4.2.1.7 of RFC2459.
This extension may be included in conforming CRLs. The extension shall not be marked critical.
[AS4539.1.2.1-2001]
3.2.4
CRL number
The cRLNumber extension conveys an increment by 1 the sequence number for each CRL issued by a
given CRL issuer through a given authority directory attribute or CRL distribution point. It allows a CRL
user to detect whether CRLs issued prior to the one being processed were also seen and processed.
17
X.509 Certificate and CRL Profiles
February 2009
This extension shall be included in all conforming CRLs. The extension shall not be marked critical.
[AS4539.1.2.1-2001]
3.2.5
Delta CRL indicator
The deltaCRLIndicator is a critical CRL extension that identifies a CRL as being a delta CRL. Delta CRLs
contain updates to revocation information previously distributed, rather than all the information that
would appear in a complete CRL. The use of delta CRLs can significantly reduce network load and
processing time in some environments. Delta CRLs are generally smaller than the CRLs they update, so
applications that obtain delta CRLs consume less network bandwidth than applications that obtain the
corresponding complete CRLs. Applications which store revocation information in a format other than
the CRL structure can add new revocation information to the local database without reprocessing
information. [RFC 2459]
ve
d
When a conforming CA issues a delta CRL, the CA MUST also issue a CRL that is complete for the given
scope. Both the delta CRL and the complete CRL MUST include the CRL number extension (see sec. 3.2.4
above). The CRL number extension in the delta CRL and the complete CRL MUST contain the same value.
When a delta CRL is issued, it MUST cover the same set of reasons and same set of certificates that were
covered by the base CRL it references. [RFC 2459]
3.2.6
hi
If a conforming CRL is a delta CRL, then it shall include this extension and shall be marked critical. A
complete CRL may or may not include the extension. If this extension is present in a complete CRL, then
it may be marked critical or non-critical.
Issuing distribution point
Ar
c
The issuingDistributionPoint extension identifies the CRL distribution point for a CRL, and indicates if
the CRL is limited to revocations for EE certificates only, for authority certificates only, or for a limited set
of reasons only. The CRL is signed by the CRL issuer’s key — CRL distribution points do not have their own
key pairs. However, for a CRL distributed via an X.500 Directory, the CRL is stored in the entry of the CRL
distribution point, which may not be the directory entry of the CRL issuer.
Conforming CRLs that include this extension shall also conform to Clause 5.3 of RFC2459.
This extension may be included in any conforming CRL. The extension shall be marked critical.
[AS4539.1.2.1-2001]
3.3
3.3.1
CRL entry extensions
Reason code
The reasonCode extension 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.
18
X.509 Certificate and CRL Profiles
February 2009
Conforming CRLs should include a reasonCode extension3. However, CAs should not generate CRLs with
the reasonCode extension set to the value unspecified, but should omit the reasonCode entry
extension if the reason is not known. The extension shall not be marked critical. [AS4539.1.2.1-2001]
3.3.2
Hold instruction code
The holdInstructionCode extension provides for inclusion of a registered instruction identifier to
indicate the action to be taken on encountering a held certificate.
Conforming CRLs that include a holdInstructionCode extension shall also conform to Clause 5.3.2 of
RFC2459.
Conforming CRLs that include a holdInstructionCode shall also include a reasonCode extension with
the value set to certificateHold. Conforming CRLs shall not contain a holdInstructionCode extension
with the OID id-holdinstruction-none. The extension shall not be marked critical. [AS4539.1.2.1-2001]
Invalidity date
ve
d
3.3.3
The invalidityDate extension indicates the date at which it is known or suspected that the private key
was compromised or that the certificate should otherwise be considered invalid. This date may be earlier
than the revocation date in the CRL entry, which is the date at which the authority processed the
revocation.
hi
Conforming CRLs that include an invalidityDate extension shall also conform to Clause 5.3.3 of RFC2459.
3.3.4
Ar
c
Conforming CRLs should include an invalidityDate extension where this information is available. The
extension shall not be marked critical. [AS4539.1.2.1-2001]
Certificate issuer
The certificateIssuer extension identifies the certificate issuer associated with an entry in an indirect
CRL, ie. a CRL that has the indirectCRL indicator set in its issuingDistributionPoint extension. If this
extension is not present on the first entry in an indirect CRL, the certificate issuer defaults to the CRL
issuer. On subsequent entries in an indirect CRL, if this extension is not present, the certificate issuer for
the entry is the same as that for the preceding entry.
This extension may be included in any conforming CRL. The extension shall be marked critical.
[AS4539.1.2.1-2001]
3
Gatekeeper privacy requirements preclude the publication of reasons for certificate revocation hence this extension should not be
included.
19
X.509 Certificate and CRL Profiles
February 2009
APPENDIX A : PROFILE SUMMARIES
A1
Required Capability
The following classifications are used to specify the requirements for inclusion of elements in
conforming certificates and CRLs, and required processing for conforming applications:
(m) Mandatory Conforming certificates shall include this element. Conforming applications
shall process this element.
●
(r) Recommended Conforming certificates should include this element. Conforming
applications should process this element
●
(o) Optional Conforming certificates may include this element. Conforming applications may
process this element.
●
(n) Not recommended Conforming certificates should not include this element. Conforming
applications should reject a certificate that contains this element.
●
(x) Prohibited Conforming certificates shall not include this element. Conforming
applications shall reject a certificate that contains this element.
●
(-) Not applicable The element is not applicable in the particular context in which the
classification is used.
hi
ve
d
●
Clause
Ar
c
Table 1 - Required Capability for certificate fields
Certificate
Field/Extension
Standard Fields
Inclusion
(c) = extn to be marked critical
if it is present
PAA
PCA
CA
EE
Ext.
Dom.
Application
support
2.2.1
version
m
m
m
m
m
m
2.2.2
serialNumber
m
m
m
m
m
m
2.2.3
signature
m
m
m
m
m
m
2.2.4
issuer
m
m
m
m
m
m
2.2.5
validity
m
m
m
m
m
m
2.2.6
subject
m
m
m
m
m
m
2.2.7
subjectPublicKeyInfo
m
m
m
m
m
m
2.2.8
issuerUniqueIdentifier
x
x
x
x
x
r*
20
X.509 Certificate and CRL Profiles
February 2009
Clause
Certificate
Field/Extension
Inclusion
(c) = extn to be marked critical
if it is present
PAA
PCA
CA
EE
Ext.
Dom.
Application
support
2.2.8
subjectUniqueIdentifier
x
x
x
x
x
r*
2.3
extensions
m
m
m
m
m
m
* Conforming applications should support this field, but are not required to process the
information contained within it
Standard Extensions
authorityKeyIdentifier
o
m
m
m
m
m
2.3.2.2
subjectKeyIdentifier
m
m
m
m
m
m
2.3.2.3
keyUsage
o
r(c)
r(c)
m(c)
r(c)
m
2.3.2.4
certificatePolicies
o
m
m
m
m
m
2.3.2.5
policyMappings
o
o
o
x
m
m
2.3.2.6
subjectAltName
o
o
o
o
o
m
2.3.2.7
issuerAltName
o
o
o
o
o
m
2.3.2.8
subjectDirectoryAttributes
n
n
n
n
o
o
2.3.2.9
basicConstraints
2.3.2.10
nameConstraints
2.3.2.11
policyConstraints
m
2.3.2.12
cRLDistributionPoints
2.3.2.13
hi
ve
d
2.3.2.1
m(c)
m(c)
n
m(c)
m
o(c)
o(c)
o(c)
x
o(c)
m
o
o
x
o
m
o
o
o
o
o
r
ExtKeyUsage
o
o
o
o
o
r
2.3.2.14
privateKeyUsagePeriod
o
o
o
o
o
r
2.3.3.1
authorityInformationAccess
o
o
o
o
o
o
o(c)
o(c)
o(c)
o(c)
o(c)
r
o
o
o
o
o
r
Ar
c
r
Future standard extensions
2.3.4.1
inhibitAnyPolicy
2.3.4.2
freshestCRL
21
X.509 Certificate and CRL Profiles
February 2009
Table 2 - Required Capability for CRL fields
Clause
CRL Field/Extension
Inclusion
Application
support
version
m
m
signature
m
m
issuer
m
m
thisUpdate
m
m
nextUpdate
m
m
revokedCertificates
o
m
m
m
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
CRL Extensions
3.2.3
3.2.4
3.2.5
3.2.6
authorityKeyIdentifier
issuerAltName
o
o
m
m
m(c) for delta CRLs
o for complete CRLs
m
o
m
reasonCode
r
r
holdInstructionCode
o
o
invalidityDate
r
o
certificateIssuer
o
m
cRLNumber
Ar
c
3.2.2
hi
3.1.1
ve
d
CRL
deltaCRLIndicator
issuingDistributionPoint
CRL Entry Extensions
3.3.1
3.3.2
3.3.3
3.3.4
22
X.509 Certificate and CRL Profiles
February 2009
APPENDIX B : DIVERGENCE FROM AS4539.1.2.1 (2001)
B1
General
This recommendation profiles Certificates and CRLs that conform to AS4539.1.2.1-2001. However, not all
certificates that conform to AS4539.1.2.1-2001 will conform to this profile. This section details the
differences between this recommendation and AS4539.1.2.1-2001.
Where differences occur, reasons are given for the recommendation and any alternative options that
were considered are also described.
B2
B2.1
Certificate Profile Differences
Version
B2.1.1
Other options considered
ve
d
This field does not differ from AS4539.1.2.1-2001.
Serial number
Ar
c
B2.2
hi
As there will be no V1 or V2 Gatekeeper compliant certificates, it was considered recommending that
conforming applications should not accept any certificates with versions V1 or V2. However, this would
require those applications to implement software modified from that required for conformance with the
Australian Standard. There is nothing to be gained in this, as CAs will only issue V3 Gatekeeper
certificates.
This field does not differ from AS4539.1.2.1-2001.
B2.3
Signature
AS4539.1.2.1 (2001) refers to AS 4539.1.3-1999 for a list of acceptable algorithms that may be used.
However, ISM is quite specific about acceptable algorithms for Commonwealth users and other users –
see www.dsd.gov.au.
However as new algorithms are likely to emerge over time this profile should be flexible enough to
accommodate new standards as they emerge, rather than require modification. Therefore, it is
preferable for a separate publication of acceptable algorithms to be maintained.
B2.4
Issuer
AS4539.1.2.1 (2001) recommends conformance with clause 4.1.2.4 of RFC2459, which in turn specifies
minimum sets of attribute types that conforming implementations must and should support.
23
X.509 Certificate and CRL Profiles
February 2009
This profile requires the Issuer DN to conform to the Standards Australia recommendation for naming
and addressing [MP 59 – 2000].
B2.5
Validity
This field does not differ from AS4539.1.2.1-2001.
B2.6
Subject
AS4539.1.2.1-2001 recommends conformance with clause 4.1.2.4 of RFC2459, which in turn specifies
minimum sets of attribute types that conforming implementations must and should support.
This profile requires the Subject DN to conform to the Standards Australia recommendation for naming
and addressing [MP 59 – 2000].
B2.7
Subject public key info
ve
d
AS4539.1.2.1-2001 requires conforming certificates to use the algorithms listed in AS 4539.1.3-1999. In
ISM DSD specifies acceptable algorithms for Commonwealth and other users – see www.dsd.gov.au .
B2.8
Unique identifiers
hi
However as new algorithms are likely to emerge over time this profile should be flexible enough to
accommodate new standards as they emerge, rather than require modification. Therefore, it is
preferable for a separate publication of acceptable algorithms to be maintained.
B2.9
Ar
c
This field does not differ from AS4539.1.2.1-2001.
Authority key identifier
This field does not differ from AS4539.1.2.1-2001.
B2.10
Subject key identifier
This field does not differ from AS4539.1.2.1-2001.
B2.11
Key usage
This field does not differ from AS4539.1.2.1-2001.
B2.12
Certificate policies
This field does not differ from AS4539.1.2.1-2001.
B2.13
Policy mappings
This field does not differ from AS4539.1.2.1-2001.
24
X.509 Certificate and CRL Profiles
February 2009
B2.14
Subject alternative name
AS4539.1.2.3-2001 specifies that if the subject field in an EE certificate is marked empty, this extension
shall be marked critical. However, this Gatekeeper profile does not allow the subject field to be marked
empty, so there is never a requirement to mark this certificate extension as critical.
B2.15
Issuer alternative name
This field does not differ from AS4539.1.2.1-2001.
B2.16
Subject directory attributes
B2.17
Basic constraints
ve
d
This field does not differ from AS4539.1.2.1-2001, except for the recommendation that it should be used
with caution, and avoided where possible. This is because its meaning is considered ambiguous in
AS 4539 and RFC 2459 and, although the extension is not currently in widespread use, there are several
applications known to utilise it for access control purposes.
This field does not differ from AS4539.1.2.1-2001.
B2.17.1
Other options considered
hi
There is a concern that by marking this extension critical, it could potentially break legacy applications.
Ar
c
However, since non-critical extensions can be treated as advisory information with the certificate, there
is a potential problem with EE certificates. The situation could arise where an entity which is not
authorised to be a CA could issue certificates, and a conforming application may unwittingly use such a
certificate.
Given that this recommendation aligns with RFC 2459 and several of its precursors and IETF draft
documents, legacy PKIX software compliant with the precursors of RFC 2459 should also recognise the
purpose of this extension. Thus the risk of disruption to legacy systems should be minimal.
B2.18
Name constraints
This field does not differ from AS4539.1.2.1-2001.
B2.19
Policy constraints
This field does not differ from AS4539.1.2.1-2001.
B2.20
CRL distribution points
This field does not differ from AS4539.1.2.1-2001.
25
X.509 Certificate and CRL Profiles
February 2009
The availability of applications to process CRLs is not yet widespread, so compliance with AS4539.1.2.12001 is recommended.
B2.21
Extended key usage
AS4539.1.2.1-2001 states that this extension may be marked critical or non-critical, whereas this profile
specifies non-critical only. Conforming applications should support and process this extension, and if it
is marked critical, they shall only use the certificate for one of the purposes indicated. RFC 2459 identifies
some extended key usage OIDs, but the list is not exhaustive. It is felt that interoperability may become
a problem if this extension is marked critical.
B2.22
Private key usage period
AS4539.1.2.1-2001 does not include any recommendation regarding the use of this extension. The
recommendation in this profile conforms with that of RFC 2459.
Authority information access
ve
d
B2.23
This field does not differ from AS4539.1.2.1-2001.
B2.24
Inhibit any policy
B2.25
Freshest CRL
hi
This is a possible future field and does not occur in AS4539.1.2.1-2001.
B3
B3.1
Ar
c
This is a possible future field and does not occur in AS4539.1.2.1-2001.
CRL Profile Differences
Version
AS4539.1.2.1-2001 recommends that conforming applications should process V1 CRLs. However, as there
will not be any V1 Gatekeeper CRLs this recommendation has been removed.
B3.2
Signature
This field only differs from AS4539.1.2.1-2001 to the extent that it recognises that the CRL may be issued
by a different entity from the original CA, and so refers to the CRL issuer’s certificate, rather than the
issuing CA’s certificate.
B3.3
Issuer name
This field does not differ from AS4539.1.2.1-2001.
26
X.509 Certificate and CRL Profiles
February 2009
B3.4
This update
This field does not differ from AS4539.1.2.1-2001.
B3.5
Next update
This field does not differ from AS4539.1.2.1-2001.
B3.6
Revoked certificates
This field does not differ from AS4539.1.2.1-2001.
B3.7
Authority key identifier
This field only differs from AS4539.1.2.1-2001 to the extent that it recognises that the CRL may be issued
by a different entity from the original CA, and so refers to the CRL issuer, rather than the CA.
Issuer alternative name
ve
d
B3.8
This field does not differ from AS4539.1.2.1-2001.
B3.9
CRL number
B3.10
Delta CRL indicator
hi
This field does not differ from AS4539.1.2.1-2001.
B3.11
Ar
c
This field is not present in AS4539.1.2.1-2001. It was an editorial decision to exclude a description of this
extension as there was an indication that it would be deprecated. The recommendation in this profile
conforms to RFC 2459.
Issuing distribution point
This field does not differ from AS4539.1.2.1-2001.
B3.12
Reason code
This field does not differ from AS4539.1.2.1-2001.
B3.12.1
Other options considered
There are privacy issues relating to acceptable values for this field. Gatekeeper privacy requirements do
not allow publication of the reasons for certificate revocation and this will be addressed as part of the
Gatekeeper Accreditation / Recognition of Service Providers.
B3.13
Hold instruction code
This field does not differ from AS4539.1.2.1-2001.
27
X.509 Certificate and CRL Profiles
February 2009
B3.14
Invalidity date
This field does not differ from AS4539.1.2.1-2001.
B3.15
Certificate issuer
Ar
c
hi
ve
d
This field does not differ from AS4539.1.2.1-2001.
28
X.509 Certificate and CRL Profiles
February 2009