Long-term Archive And Notary C. Wallace
Services (LTANS) Cygnacom Solutions
Internet-Draft June 20, 2007
Intended status: Standards Track
Expires: December 22, 2007
Using SCVP to Convey Long-term Evidence Records
draft-ietf-ltans-ers-scvp-03.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 December 22, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Wallace Expires December 22, 2007 [Page 1]
Internet-Draft Evidence Records via SCVP June 2007
Abstract
The Simple Certificate Validation Protocol (SCVP) defines an
extensible means of delegating the development and validation of
certification paths to a server. It can be used to support the
development and validation of certification paths well after the
expiration of the certificates in the path by specifying a time of
interest in the past. The Evidence Record Syntax (ERS) defines
structures, called evidence records, to support non-repudiation of
existence of data. Evidence records can be used to preserve
materials that comprise a certification path such that trust can be
established in the certificates after the expiration of the
certificates in the path and after the cryptographic algorithms used
to sign the certificates in the path are no longer secure. This
document describes an application of SCVP to serve this purpose using
the WantBack feature of SCVP to convey evidence records.
Wallace Expires December 22, 2007 [Page 2]
Internet-Draft Evidence Records via SCVP June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
2. Concept of Operations . . . . . . . . . . . . . . . . . . . . 6
3. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. WantBacks . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Evidence record for a complete certification path . . . . 10
5.2. Evidence record for a partial certification path . . . . . 10
5.3. Evidence record for a public key certificate . . . . . . . 11
5.4. Evidence record for a revocation information . . . . . . . 11
5.5. Evidence record for any replyWantBack . . . . . . . . . . 11
5.6. Partial certification path . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Wallace Expires December 22, 2007 [Page 3]
Internet-Draft Evidence Records via SCVP June 2007
1. Introduction
Digital signatures are frequently verified using public key
infrastructure (PKI) artifacts, including public key certificates and
certificate revocation information. 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.
SCVP [I-D.ietf-pkix-scvp] provides a means of delegating
certification path construction and/or validation to a server,
including the ability to request the status of a certificate relative
to a time in the past. SCVP does not define a means of providing or
validating long-term non-repudiation information. ERS
[I-D.ietf-ltans-ers] defines a syntax 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. LTAP [I-D.ietf-ltans-ltap] defines a
protocol for communicating with a long-term archive (LTA) server for
the purposes of preserving evidence records and data. Clients store,
retrieve and delete data using LTAP; LTAs maintain evidence records
covering data submitted by clients.
This document defines an application of SCVP to permit retrieval of
an evidence record corresponding to information returned by the SCVP
server by creating an association between an evidence record and
information contained in an SCVP response. The SCVP response can
then in turn be used to verify archived data objects retrieved using
LTAP. Separating the preservation of the certification path
information from the preservation of data enables the LTA to store
archived data objects more efficiently, i.e., complete verification
information need not be stored with each archived data object.
Verifiers can more efficiently process archived data object by
reusing the same certification path information to verify multiple
archived data objects of similar vintage without retrieving and/or
validating the same PKI artifacts multiple times.
1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Wallace Expires December 22, 2007 [Page 4]
Internet-Draft Evidence Records via SCVP June 2007
document are to be interpreted as described in [RFC2119].
Wallace Expires December 22, 2007 [Page 5]
Internet-Draft Evidence Records via SCVP June 2007
2. Concept of Operations
During certification path processing, active SCVP servers may
encounter a large portion of the PKI artifacts generated by a
particular PKI. By storing and preserving these artifacts, an SCVP
server can respond to queries for certificate status over very long
periods of time. Optionally, SCVP servers may actively seek PKI
information for storage and preservation even when no query is made
that requires the information during its period of validity in order
to service future queries relative to any point in time.
SCVP permits clients to request as much or as little information as
desired from the SCVP server. Clients include zero or more OIDs
indicating the type(s) of information the server should include in
the response. By defining additional OID values, clients can request
an evidence record for specific types of information returned by the
SCVP server. This document defines OIDs to permit the retrieval of
evidence records for the following four types of information:
- end entity certificates
- certification paths containing end entity certificates through
trust anchors
- certification paths containing intermediate certificates through
trust anchors
- revocation information.
Additionally, an OID is defined to permit inclusion of a single OID
indicating an evidence record is desired for all information
requested via the WantBack mechanism.
By associating evidence records with information maintained by an
SCVP server, clients are able to determine the status of certificates
over very long periods of time using SCVP without consulting
additional resources. The nature of SCVP servers is well suited to
preservation of infrastructure materials. Additionally, the SCVP
server's signature over an SCVP response can secure the transmission
of trust anchors included in evidence records, allowing clients to
refrain from establishing additional trust relationships with LTAs.
The transactions used to verify an archived data object using LTAP
and the SCVP WantBacks described in this document are as follows:
- Client retrieves a signed archived data object from an LTA using
LTAP
Wallace Expires December 22, 2007 [Page 6]
Internet-Draft Evidence Records via SCVP June 2007
- Client prepares an SCVP request to validate the signer's
certificate at the time of interest and includes WantBacks for
evidence records corresponding to the PKI artifacts required to
validate the signer's certificate
- SCVP server returns a response with status as of time of
interest and including requested evidence records
- Client processes the SCVP request, determines the status and
verifies the evidence records
- Client verifies signatures in the archived data object using the
validated signer's certificate
Wallace Expires December 22, 2007 [Page 7]
Internet-Draft Evidence Records via SCVP June 2007
3. Requests
Clients request long-term archive evidence records from an SCVP
server by including one of the following OIDs in the wantBack field
of a CVRequest sent to an SCVP server:
- id-swb-ers-best-cert-path
- id-swb-ers-partial-cert-path
- id-swb-ers-pkc-cert
- id-swb-ers-revocation-info
- id-swb-ers-all
Additionally, id-swb-partial-cert-path is defined to permit clients
to request a partial certification path consisting of the CA who
issued the end entity certificate through a trust anchor. This is
similar to the id-swb-best-cert-path WantBack defined in SCVP except
the resulting replyWantBack will contain a CertBundle containing the
certification path minus the end entity certificate.
For each id-swb-ers OID except id-swb-ers-all, an EvidenceRecord (as
defined in [I-D.ietf-ltans-ers]) covering the corresponding
information in the response will be returned as a replyWantBack. For
example, if a client wishes to obtain a certification path and
revocation information plus an evidence record for each, the SCVP
request would include the following four replyWantBack OIDs: id-swb-
best-cert-path, id-swb-pkc-revocation-info, id-swb-ers-best-cert-path
and id-swb-ers-revocation-info.
Alternatively, for id-swb-ers-all, an EvidenceRecordWantBacks
structure will be returned containing an EvidenceRecord for each
information item contained in the replyWantBacks field. For example,
if a client wishes to obtain a certification path and revocation
information plus an evidence record for each, the SCVP request would
include the following four replyWantBack OIDs: id-swb-best-cert-path,
id-swb-pkc-revocation-info and id-swb-ers-all.
Wallace Expires December 22, 2007 [Page 8]
Internet-Draft Evidence Records via SCVP June 2007
4. Responses
When a client request contains a WantBack request for an evidence
record, the response generated MUST include the replyWantBack
containing the requested information plus a replyWantBack containing
the evidence record corresponding to that information. For each id-
swb-ers OID except id-swb-ers-pkc-cert, the evidence record is
calculated over the value of the value field in the corresponding
replyWantBack; the tag and length bytes are not covered by the
evidence record. For example, if a client request contains id-swb-
pkc-best-cert-path and id-swb-ers-best-cert-path, the resulting
response will contain a replyWantBack of each type where the evidence
record covers the DER encoded CertBundle returned in the id-swb-pkc-
best-cert-path replyWantBack. For id-swb-ers-pkc-cert, the evidence
record is calculated over the value of the cert field in the
CertReply object.
If the server can not return an EvidenceRecord for the requested
information, a replyWantBack of the appropriate type MUST be returned
with an empty value field. For example, if a client requests id-swb-
ers-pkc-cert and the server cannot fulfill the request, the resulting
response will contain a replyWantBack with the wb field set to id-
swb-ers-pkc-cert and the value field empty, i.e., zero length.
Wallace Expires December 22, 2007 [Page 9]
Internet-Draft Evidence Records via SCVP June 2007
5. WantBacks
The following sections describe each WantBack defined in this
document.
5.1. Evidence record for a complete certification path
The id-swb-ers-best-cert-path OID is used to request an evidence
record for a complete certification path. It is used in conjunction
with the id-swb-best-cert-path OID. Requests containing id-swb-ers-
best-cert-path as a WantBack MUST also contain id-swb-best-cert-path.
Responses containing id-swb-ers-best-cert-path MUST also contain id-
swb-best-cert-path.
An SCVP server may maintain evidence records for complete
certification paths, i.e., certification paths containing all
certificates from end entity to trust anchor. The evidence record is
calculated over the CertBundle returned via the id-swb-best-cert-path
replyWantBack. In such cases, a signature within the archived data
object may be verified using an end entity certificate returned via
SCVP. The end entity certificate can be verified using SCVP using a
request containing id-swb-ers-best-cert-path, id-swb-best-cert-path,
id-swb-pkc-revocation-info and id-swb-ers-revocation-info
5.2. Evidence record for a partial certification path
The id-swb-ers-partial-cert-path OID is used to request an evidence
record for a partial certification path. It is used in conjunction
with the id-swb-partial-cert-path OID. Requests containing id-swb-
ers-partial-cert-path as a WantBack MUST also contain id-swb-partial-
cert-path. Responses containing id-swb-ers-partial-cert-path MUST
also contain id-swb-partial-cert-path.
As an alternative to relying on SCVP to obtain evidence records for
end entity certificates, the certificate could be included in the
archived data object(s) submitted to an LTA. In such cases, a
signature within the archived data object may be verified using the
included end entity certificate, which is protected by the evidence
record covering the archived data object including the certificate.
The end entity certificate can be verified using SCVP using a request
containing id-swb-pkc-partial-cert-path, id-swb-ers-partial-cert-
path, id-swb-pkc-revocation-info and id-swb-ers-revocation-info.
Unlike the partial certification path, the revocation information
includes material that can be used to determine the status of the end
entity certificate.
By maintaining an evidence record for a partial certification path,
SCVP servers can achieve greater storage efficiency.
Wallace Expires December 22, 2007 [Page 10]
Internet-Draft Evidence Records via SCVP June 2007
5.3. Evidence record for a public key certificate
The id-swb-ers-pkc-cert OID is used to request an evidence record for
an individual public key certificate. It is used in conjunction with
the id-swb-pkc-cert OID. Requests containing id-swb-ers-pkc-cert as
a WantBack MUST also contain id-swb-pkc-cert. Responses containing
id-swb-ers-pkc-cert MUST also contain id-swb-pkc-cert.
SCVP servers may maintain evidence records for individual
certificates. This enables clients to omit the signer's certificate
from archived data object(s) submitted to an LTA. In such cases, a
signature within the archived data object may be verified using an
end entity certificate returned via SCVP. The end entity certificate
can be verified using SCVP using a request containing id-swb-pkc-
cert, id-swb-ers-pkc-cert, id-swb-pkc-partial-cert-path, id-swb-ers-
partial-cert-path, id-swb-pkc-revocation-info and id-swb-ers-
revocation-info.
5.4. Evidence record for a revocation information
The id-swb-ers-revocation-info OID is used to request an evidence
record for a set of revocation information. It is used in
conjunction with the id-swb-revocation-info OID. Requests containing
id-swb-ers-revocation-info as a WantBack MUST also contain id-swb-
revocation-info. Responses containing id-swb-ers-revocation-info
MUST also contain id-swb-revocation-info.
An SCVP server may maintain evidence records for revocation
information. Revocation information may be provided in the form of
CRLs or OCSP responses. Cumulative CRLs may be generated for
archiving to simplify evidence record maintenance.
5.5. Evidence record for any replyWantBack
An SCVP server may maintain evidence records for additional types of
information that can be returned using the wantBack mechanism, e.g.,
attribute certificate information. The id-swb-ers-all OID provides a
shorthand means for clients to request evidence records for all
information returned via in the replyWantBacks field. Since id-swb-
ers-all can result in the return of multiple evidence records in the
response, a mechanism is needed to associate an evidence record with
the type of information covered by the evidence record. The
EvidenceRecordWantBacks structure provides a flexible means of
conveying an evidence record for different types of information.
Wallace Expires December 22, 2007 [Page 11]
Internet-Draft Evidence Records via SCVP June 2007
EvidenceRecordWantBack ::= SEQUENCE
{
targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL
}
EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1...MAX) OF EvidenceRecordWantBack
EvidenceRecordWantBacks is a SEQUENCE OF EvidenceRecordWantBack
structures. The targetWantBack field indicates the type of
replyWantBack is covered by the associated EvidenceRecord. The
evidenceRecord field, if present, contains an EvidenceRecord
structure calculated over the replyWantBack indicated by the
targetWantBack field. There MUST be a one to one correspondence
between other replyWantBack objects and objects in the
EvidenceRecordWantBacks collection. If a server does not have an
EvidenceRecord for particular replyWantBack object, an
EvidenceRecordWantBack with the evidenceRecord field absent should be
included in the EvidenceRecordWantBacks collection.
5.6. Partial certification path
The id-swb-partial-cert-path is an alternative to id-swb-best-cert-
path. This is the only OID defined in this document for which an
EvidenceRecord is not returned in the response. For efficiency, SCVP
servers that maintain evidence records for certification paths may
only do so for partial paths instead of maintaining one or more paths
for each end entity certificate.
SCVP clients can include id-swb-pkc-partial-cert-path in a request
when a partial certification path is required. This would typically
be included along with id-swb-ers-partial-cert-path to account for
the fact that some SCVP servers only produce evidence records for
partial paths for storage and computational efficiency reasons. In
such cases, a separate evidence record may be available for the end
entity certificate by including id-swb-pkc-cert and id-swb-ers-pkc-
cert in the request.
Wallace Expires December 22, 2007 [Page 12]
Internet-Draft Evidence Records via SCVP June 2007
6. Security Considerations
For security considerations specific to SCVP, see
[I-D.ietf-pkix-scvp]. For security considerations specific to ERS,
see [I-D.ietf-ltans-ers].
The signature on the SCVP response containing one or more ERS
structures must be verified using a public key trusted by the relying
party. The response may contain trust anchors used to verify
interior layers of an ERS structure. The trust anchors are protected
by the SCVP server's signature covering the response. The relying
party may elect to use the trust anchors conveyed in the response or
ignore the trust anchors in favor of trust anchors retrieved out of
band. Relying parties should ignore trust anchors contained in
unsigned SCVP responses.
Usage of cumulative CRLs may require additional extensions to
existing standards. Cumulative CRLs must contain revocation
information for all certificates within the scope of the CRL,
including expired certificates, must provide indications of when a
certificate was placed on hold and removed from hold and must provide
an indication of when a CRL entry first appeared on a CRL. One
approach tailored for long-term archiving purposes, which may be
described in a subsequent draft, is to generate CRLs with a fixed
thisUpdate value and containing a new CRL entry extension identifying
the thisUpdate of the CRL on which the entry first appeared. An LTA
only needs to maintain the latest cumulative CRL in order to provide
revocation status for all certificates within the scope and period of
the CRL. In some cases, the original CRLs may be required.
The mechanism described in this document focuses on preserving PKI
artifacts and uses SCVP to convey the preservation evidence. A
simpler alternative, or additional means, would be to define a
directory entry to contain EvidenceRecords for the desired artifacts,
e.g., certificates and cumulative CRLs.
Wallace Expires December 22, 2007 [Page 13]
Internet-Draft Evidence Records via SCVP June 2007
7. IANA Considerations
This document has no actions for IANA.
Wallace Expires December 22, 2007 [Page 14]
Internet-Draft Evidence Records via SCVP June 2007
8. References
8.1. Normative References
[I-D.ietf-ltans-ers]
Brandner, R., "Evidence Record Syntax (ERS)",
draft-ietf-ltans-ers-15 (work in progress), June 2007.
[I-D.ietf-pkix-scvp]
Malpani, A., "Server-based Certificate Validation Protocol
(SCVP)", draft-ietf-pkix-scvp-31 (work in progress),
January 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.ietf-ltans-ltap]
Jerman-Blazic, A., "Long-term Archive Protocol (LTAP)",
draft-ietf-ltans-ltap-04 (work in progress), March 2007.
Wallace Expires December 22, 2007 [Page 15]
Internet-Draft Evidence Records via SCVP June 2007
Appendix A. ASN.1 Module
LTANS_SCVP_EXTENSION
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers-scvp(5)
id-mod-ers-scvp-v1(1) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
id-swb
FROM SCVP
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0) 21 }
EvidenceRecord
FROM ERS
{iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers88(2)
id-mod-ers88-v1(1) };
id-swb-partial-cert-path OBJECT IDENTIFIER ::= {id-swb 15 }
id-swb-ers-pkc-cert OBJECT IDENTIFIER ::= {id-swb 16 }
id-swb-ers-best-cert-path OBJECT IDENTIFIER ::= {id-swb 17 }
id-swb-ers-partial-cert-path OBJECT IDENTIFIER ::= {id-swb 18 }
id-swb-ers-revocation-info OBJECT IDENTIFIER ::= {id-swb 19 }
id-swb-ers-all OBJECT IDENTIFIER ::= {id-swb 20 }
EvidenceRecordWantBack ::= SEQUENCE
{
targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL
}
EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
END
Wallace Expires December 22, 2007 [Page 16]
Internet-Draft Evidence Records via SCVP June 2007
Author's Address
Carl Wallace
Cygnacom Solutions
Suite 5200
7925 Jones Branch Drive
McLean, VA 22102
Email: cwallace@cygnacom.com
Wallace Expires December 22, 2007 [Page 17]
Internet-Draft Evidence Records via SCVP June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Wallace Expires December 22, 2007 [Page 18]