Using the Server-Based Certificate Validation Protocol (SCVP) to Convey Long-Term Evidence Records
RFC 5276
|
| Document |
Type |
|
RFC - Proposed Standard
(August 2008; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 5276 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Tim Polk
|
|
Send notices to |
|
(None)
|
Network Working Group C. Wallace
Request for Comments: 5276 Cygnacom Solutions
Category: Standards Track August 2008
Using the Server-Based Certificate Validation Protocol (SCVP) to
Convey Long-Term Evidence Records
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Server-based 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 the non-repudiation
of the existence of data. Evidence records can be used to preserve
materials that comprise a certification path such that trust in the
certificates can be established 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 usage of the SCVP WantBack feature to convey
evidence records, enabling SCVP responders to provide preservation
evidence for certificates and certificate revocation lists (CRLs).
Wallace Standards Track [Page 1]
RFC 5276 Evidence Records via SCVP August 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Concept of Operations . . . . . . . . . . . . . . . . . . . . 4
3. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. WantBacks . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Evidence Record for a Complete Certification Path . . . . 7
5.2. Evidence Record for a Partial Certification Path . . . . . 7
5.3. Evidence Record for a Public Key Certificate . . . . . . . 8
5.4. Evidence Record for Revocation Information . . . . . . . . 8
5.5. Evidence Record for Any replyWantBack . . . . . . . . . . 8
5.6. Partial Certification Path . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 11
Wallace Standards Track [Page 2]
RFC 5276 Evidence Records via SCVP August 2008
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 the acquisition of
different types of information generated by multiple PKIs. To verify
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 [RFC5055] 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 [RFC4998] 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 [LTANS-LTAP] defines a
protocol for communicating with a long-term archive (LTA) server for
Show full document text