Long-term Archive And Notary C. Wallace
Services (LTANS) Cygnacom Solutions
Internet-Draft October 23, 2006
Expires: April 26, 2007
Infrastructure Support for Retention of PKI Artifacts
draft-ietf-ltans-pki-retention-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
In most PKIs, directory servers are used to provide current
certificates and revocation information to relying parties. In
situations where certificates must be validated relative to a time in
the past, relying parties often have no means of obtaining the
necessary PKI artifacts. This specification defines several
directory attributes to support validation using historical PKI
artifacts.
Wallace Expires April 26, 2007 [Page 1]
Internet-Draft PKI Artifact Retention October 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Concept of Operations . . . . . . . . . . . . . . . . . . . . 4
3. Object classes . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Public key certificates . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 9
Appendix B. Revocation information . . . . . . . . . . . . . . . 10
B.1. Historical CRLs . . . . . . . . . . . . . . . . . . . . . 10
B.2. Entry Revocation Publication extension . . . . . . . . . . 11
B.3. Historical CRL issuance extension . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 14
Wallace Expires April 26, 2007 [Page 2]
Internet-Draft PKI Artifact Retention October 2006
1. Introduction
Digital signatures are frequently verified using public key
infrastructure (PKI) artifacts such as public key certificates and
certificate revocation lists (CRLs). Verifiers construct and
validate certification paths from a public key certificate containing
the public key used to verify the signature to a trusted public key.
Construction of a certification path may require acquisition of
different types of information generated by multiple PKIs. When
verifying digital signatures many years after signature generation,
additional considerations must be addressed. For example, some
necessary PKI artifacts may no longer be available, some may have
expired and the cryptographic algorithms or keys used in generating
digital signatures may no longer provide the desired degree of
security.
The "Standard Certificate Validation Protocol" (SCVP) [I-D.ietf-pkix-
scvp] defines a means of delegating certification path construction
and/or validation to a server, including the ability to request the
server to perform the operations relative to a time in the past. The
"Evidence Record Syntax" (ERS) [I-D.ietf-ltans-ers] defines
structures for preserving materials over long periods of time through
a regimen that includes periodic re-signing of relevant materials
using newer keys and stronger cryptographic algorithms. "Using SCVP
to Convey Evidence Records" [I-D.ietf-ltans-ers-scvp] defines a means
of using SCVP to retrieve evidence records covering historical PKI
artifacts.
Directory servers are frequently used to make PKI artifacts available
for use by public key-enabled applications. However, in many PKIs,
artifacts are removed from the directory when the artifact is updated
by a newer version or the artifact expires. This document describes
a means of using LDAP or X.500 directory servers to retrieve
historical PKI artifacts and, optionally, associated evidence
records.
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Wallace Expires April 26, 2007 [Page 3]
Internet-Draft PKI Artifact Retention October 2006
2. Concept of Operations
Public key-enabled applications build and validate certification
paths in support of functions including digital signature
verification and public key encryption. In many cases, the materials
used to validate a certification path are available via an X.500 or
LDAP directory in accord with the schema defined in [RFC2587]. For
many reasons, including size constraints on the server and
performance impact on relying parties, directories usually contain
PKI artifacts that are current, i.e., non-expired and most recent.
Applications requiring access to historical PKI artifacts, i.e., not
the most recent and possibly expired, are forced to rely upon other
mechanisms. This document defines an object class and a set of
directory attributes that complement those defined in [RFC2587] for
the purpose of making historical PKI artifacts available.
Wallace Expires April 26, 2007 [Page 4]
Internet-Draft PKI Artifact Retention October 2006
3. Object classes
Two object classes are defined for historical certificates and CRLs:
historicalPKIEntity and historicalCRLDistributionPoint. These
auxiliary object classes MAY be used to represent entities associated
with historical PKI artifacts.
historicalPKIEntity OBJECT-CLASS ::=
{
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {historicalCertificate}
ID TBD
}
historicalCRLDistributionPoint OBJECT-CLASS ::=
{
SUBCLASS OF {top}
KIND auxiliary
MAY CONTAIN {historicalCRL}
ID TBD
}
This specification differs from [RFC2587] by not defining separate
object classes or attributes to delineate between end entities and
certification authorities.
Wallace Expires April 26, 2007 [Page 5]
Internet-Draft PKI Artifact Retention October 2006
4. Public key certificates
Public key certificates are digitally signed. As such, certificates
are subject to the same concerns as described for digitally signed
forms, contracts, etc. in [I-D.ietf-ltans-ers]. To address these
concerns, the integrity of public key certificates can be protected
by generating and maintaining an evidence record covering the
certificate. A certificate and an evidence record can be bound
together using the structure defined below. Certificates are defined
in [RFC3280] and evidence records are defined in [I-D.ietf-ltans-
ers].
HistoricalCertificate ::= SEQUENCE
{
certificate Certificate,
evidenceRecord EvidenceRecord OPTIONAL
}
HistoricalCertificates can be made available via an X.500 or LDAP
directory using the following attribute. When a certificate is to be
removed from a directory due to replacement or due to expiration, it
MAY be removed from the userCertificate or cACertificate attribute
and it SHOULD be added to the historicalCertificate attribute. An
evidence record for the certificate MAY be requested at that time or
at a later time.
historicalCertificate ATTRIBUTE ::=
{
WITH SYNTAX HistoricalCertificate
EQUALITY MATCHING RULE historicalCertificateExactMatch,
ID TBD
}
Wallace Expires April 26, 2007 [Page 6]
Internet-Draft PKI Artifact Retention October 2006
5. Security Considerations
Since the information stored in the attributes defined in this
specification are signed, no additional integrity service is
required.
Security considerations with respect to retrieval, addition, deletion
and modification of the information supported by this schema
definition are addressed in [RFC2559].
The timing of the application or update of evidence records is a
matter of local policy. Security considerations associated with
evidence records are described in [I-D.ietf-ltans-ers].
Wallace Expires April 26, 2007 [Page 7]
Internet-Draft PKI Artifact Retention October 2006
6. References
6.1. Normative References
[I-D.ietf-ltans-ers]
Brandner, R., "Evidence Record Syntax (ERS)",
draft-ietf-ltans-ers-07 (work in progress), May 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
6.2. Informative References
[I-D.ietf-ltans-ers-scvp]
Wallace, C., "Using SCVP to Convey Long-term Evidence
Records", draft-ietf-ltans-ers-scvp-01 (work in progress),
May 2006.
[I-D.ietf-pkix-scvp]
Malpani, A., "Server-based Certificate Validation Protocol
(SCVP)", draft-ietf-pkix-scvp-27 (work in progress),
June 2006.
[RFC2559] Boeyen, S., Howes, T., and P. Richard, "Internet X.509
Public Key Infrastructure Operational Protocols - LDAPv2",
RFC 2559, April 1999.
[RFC2587] Boeyen, S., Howes, T., and P. Richard, "Internet X.509
Public Key Infrastructure LDAPv2 Schema", RFC 2587,
June 1999.
Wallace Expires April 26, 2007 [Page 8]
Internet-Draft PKI Artifact Retention October 2006
Appendix A. ASN.1 Module
LTANS_PKI_RETENTION
-- { iso(1) identified-organization(3) dod(6) internet(1)
-- security(5) mechanisms(5) pkix(7) id-mod(0) TBD }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
Certificate, CertificateList, Time
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
mod(0) pkix1-explicit(18) }
EvidenceRecord
FROM ERS
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ers(TBD) }
HistoricalCertificate ::= SEQUENCE
{
certificate Certificate,
evidenceRecord EvidenceRecord OPTIONAL
}
HistoricalCRL ::= SEQUENCE
{
crl CertificateList,
evidenceRecord EvidenceRecord OPTIONAL
}
EntryRevocationPublication ::= Time
HistoricalCRLIssuance ::= Time
END
Wallace Expires April 26, 2007 [Page 9]
Internet-Draft PKI Artifact Retention October 2006
Appendix B. Revocation information
Preservation of revocation information is more complicated than
preservation of certificates due, primarily, to the volume of
revocation information generated in most PKIs, i.e., CRLs are
generated more frequently than certificates and are often much
larger. CRLs are signed and the signatures require preservation.
However, the number of CRLs makes preservation difficult and
complicates validation operations for relying parties. A cumulative
CRL provides a better target for preservation. However, cumulative
CRLs introduce additional processing rules. To account for the
HoldInstruction extension, all entries on a CRL must be reviewed, the
entries applicable to a certificate sorted and the time of interest
compared to the sorted list to determine if the certificate was on
hold at that time.
X.509 specifies a the expiredCertsOnCRL CRL extension, that is not
present in [RFC3280], to indicate that the CRL contains expired
certificates. The extension is expressed as a GeneralizedTime value
that provides the time at or since which certificates may have
expired but will still appear on the CRL, i.e., certificates that
expired before that time do not appear on the CRL. Relying parties
using a CRL of this sort must recognize that the time of interest for
a path validation operation may fall outside the thisUpdate/
nextUpdate period of a cumulative CRL. The following section
describes a variation on the X.509 CumulativeCRL extension that
preserves the property where thisUpdate is less than or equal to the
time of interest and nextUpdate is greater than or equal to the time
of interest.
B.1. Historical CRLs
To avoid preserving every CRL instance generated within a PKI, an
historical CRL can be generated and maintained. An historical CRL is
a CRL with the following properties:
- The thisUpdate field is fixed and contains the time
corresponding to the instantiation of the CA(s) covered by the
CRL.
- Entries optionally include an extension indicating the
thisUpdate value from the first CRL on which the entry appeared.
- The CRL structure is optionally associated with an
EvidenceRecord.
Historical CRLs are defined as follows.
Wallace Expires April 26, 2007 [Page 10]
Internet-Draft PKI Artifact Retention October 2006
HistoricalCRL ::= SEQUENCE
{
crl CertificateList,
evidenceRecord EvidenceRecord OPTIONAL
}
CRL issuers need not generate an historical CRL upon each CRL
issuance. Historical CRLs can be generated on a less frequent basis
since certification path validation operations relative to the
current time can be serviced using conventional CRLs. When an
historical CRL is generated, the thisUpdate time MUST NOT change from
the value in the previous historical CRL. The new CRL MUST replace
the previous historical CRL in the historicalCRL directory attribute.
The thisUpdate value in the first historical CRL issued by a CRL
issuer SHOULD be set to the earliest notBefore value from the set of
certificates issued by the CAs covered by the CRL. After a CA no
longer needs to issue CRLs, the final HistoricalCRL can be preserved
by periodically updating the evidence record as described in
[I-D.ietf-ltans-ers].
For sake of simplicity, historical CRLs should not be indirect CRLs
and should not be delta CRLs. Where partitioned, historical CRLs
MUST adhere to the partioning scheme used by the corresponding
conventional CRLs.
B.2. Entry Revocation Publication extension
This CRL entry extension identifies the thisUpdate time from the CRL
on which the entry first appeared. If this extension is not present
on the first entry in a CRL, the revocation publication value
defaults to the thisUpdate value of the CRL. On subsequent entries,
if this extension is not present, the revocation publication value
for the entry is the same as that for the preceding entry. This
extension is defined as follows:
EntryRevocationPublication ::= Time
B.3. Historical CRL issuance extension
This optional CRL extension indicates the CRL is an historical CRL,
i.e., the thisUpdate time is not based on the time of issuance. The
extension is used to convey the issuance time and is defined as
follows:
Wallace Expires April 26, 2007 [Page 11]
Internet-Draft PKI Artifact Retention October 2006
HistoricalCRLIssuance ::= Time
If used by conforming CRL issuers, this extension MUST always be non-
critical.
HistoricalCRLs can be made available via an X.500 or LDAP directory
using the following attribute.
historicalCRL ATTRIBUTE ::=
{
WITH SYNTAX HistoricalCRL
EQUALITY MATCHING RULE historicalCRLExactMatch,
ID TBD
}
Historical CRLs are not intended to replace CRLs used by applications
performing certification path validation relative to the current
time. CRL issuers should continue to publish conventional CRLs.
Wallace Expires April 26, 2007 [Page 12]
Internet-Draft PKI Artifact Retention October 2006
Author's Address
Carl Wallace
Cygnacom Solutions
Suite 5200
7925 Jones Branch Drive
McLean, VA 22102
Email: cwallace@cygnacom.com
Wallace Expires April 26, 2007 [Page 13]
Internet-Draft PKI Artifact Retention October 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wallace Expires April 26, 2007 [Page 14]
