< draft-ietf-ltans-ers-scvp-06.txt   draft-ietf-ltans-ers-scvp-07.txt >
Long-term Archive And Notary C. Wallace Long-term Archive And Notary C. Wallace
Services (LTANS) Cygnacom Solutions Services (LTANS) Cygnacom Solutions
Internet-Draft February 14, 2008 Internet-Draft June 20, 2008
Intended status: Standards Track Intended status: Standards Track
Expires: August 17, 2008 Expires: December 22, 2008
Using SCVP to Convey Long-term Evidence Records Using Server-based Certificate Validation Protocol (SCVP) to Convey
draft-ietf-ltans-ers-scvp-06.txt Long-term Evidence Records
draft-ietf-ltans-ers-scvp-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 17, 2008. This Internet-Draft will expire on December 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Simple Certificate Validation Protocol (SCVP) defines an The Server-based Certificate Validation Protocol (SCVP) defines an
extensible means of delegating the development and validation of extensible means of delegating the development and validation of
certification paths to a server. It can be used to support the certification paths to a server. It can be used to support the
development and validation of certification paths well after the development and validation of certification paths well after the
expiration of the certificates in the path by specifying a time of expiration of the certificates in the path by specifying a time of
interest in the past. The Evidence Record Syntax (ERS) defines interest in the past. The Evidence Record Syntax (ERS) defines
structures, called evidence records, to support non-repudiation of structures, called evidence records, to support non-repudiation of
existence of data. Evidence records can be used to preserve existence of data. Evidence records can be used to preserve
materials that comprise a certification path such that trust in the materials that comprise a certification path such that trust in the
certificates can be established after the expiration of the certificates can be established after the expiration of the
certificates in the path and after the cryptographic algorithms used certificates in the path and after the cryptographic algorithms used
to sign the certificates in the path are no longer secure. This to sign the certificates in the path are no longer secure. This
document describes an application of SCVP to serve this purpose using document describes usage of the SCVP WantBack feature to convey
the WantBack feature of SCVP to convey evidence records. evidence records, enabling SCVP responders to provide preservation
evidence for certificates and certificate revocation lists (CRLs).
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
2. Concept of Operations . . . . . . . . . . . . . . . . . . . . 5 2. Concept of Operations . . . . . . . . . . . . . . . . . . . . 5
3. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. WantBacks . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. WantBacks . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Evidence record for a complete certification path . . . . 9 5.1. Evidence record for a complete certification path . . . . 9
5.2. Evidence record for a partial certification path . . . . . 9 5.2. Evidence record for a partial certification path . . . . . 9
5.3. Evidence record for a public key certificate . . . . . . . 10 5.3. Evidence record for a public key certificate . . . . . . . 10
5.4. Evidence record for revocation information . . . . . . . . 10 5.4. Evidence record for revocation information . . . . . . . . 10
5.5. Evidence record for any replyWantBack . . . . . . . . . . 10 5.5. Evidence record for any replyWantBack . . . . . . . . . . 11
5.6. Partial certification path . . . . . . . . . . . . . . . . 11 5.6. Partial certification path . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
Digital signatures are frequently verified using public key Digital signatures are frequently verified using public key
infrastructure (PKI) artifacts, including public key certificates and infrastructure (PKI) artifacts, including public key certificates and
certificate revocation information. Verifiers construct and validate certificate revocation information. Verifiers construct and validate
certification paths from a public key certificate containing the certification paths from a public key certificate containing the
public key used to verify the signature to a trusted public key. public key used to verify the signature to a trusted public key.
Construction of a certification path may require acquisition of Construction of a certification path may require acquisition of
different types of information generated by multiple PKIs. To verify different types of information generated by multiple PKIs. To verify
skipping to change at page 10, line 32 skipping to change at page 10, line 32
from archived data object(s) submitted to an LTA. In such cases, a from archived data object(s) submitted to an LTA. In such cases, a
signature within the archived data object may be verified using an signature within the archived data object may be verified using an
end entity certificate returned via SCVP. The end entity certificate end entity certificate returned via SCVP. The end entity certificate
can be verified using SCVP using a request containing id-swb-pkc- can be verified using SCVP using a request containing id-swb-pkc-
cert, id-swb-ers-pkc-cert, id-swb-partial-cert-path, id-swb-ers- cert, id-swb-ers-pkc-cert, id-swb-partial-cert-path, id-swb-ers-
partial-cert-path, id-swb-pkc-revocation-info and id-swb-ers- partial-cert-path, id-swb-pkc-revocation-info and id-swb-ers-
revocation-info. revocation-info.
5.4. Evidence record for revocation information 5.4. Evidence record for revocation information
The id-swb-ers-revocation-info OID is used to request an evidence The id-swb-ers-revocation-info OID is used to request evidence
record for a set of revocation information. It is used in records for a set of revocation information. It is used in
conjunction with the id-swb-revocation-info OID. Requests containing conjunction with the id-swb-revocation-info OID. Requests containing
id-swb-ers-revocation-info as a WantBack MUST also contain id-swb- id-swb-ers-revocation-info as a WantBack MUST also contain id-swb-
revocation-info. Responses containing id-swb-ers-revocation-info revocation-info. Responses containing id-swb-ers-revocation-info
MUST also contain id-swb-revocation-info. MUST also contain id-swb-revocation-info. A sequence of evidence
records is returned, with one evidence record provided for each
element in id-swb-revocation-info.
EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord
An SCVP server may maintain evidence records for revocation An SCVP server may maintain evidence records for revocation
information. Revocation information may be provided in the form of information. Revocation information may be provided in the form of
CRLs or OCSP responses. Cumulative CRLs may be generated for CRLs or OCSP responses. Cumulative CRLs may be generated for
archiving to simplify evidence record maintenance. archiving to simplify evidence record maintenance.
5.5. Evidence record for any replyWantBack 5.5. Evidence record for any replyWantBack
An SCVP server may maintain evidence records for additional types of An SCVP server may maintain evidence records for additional types of
information that can be returned using the wantBack mechanism, e.g., information that can be returned using the wantBack mechanism, e.g.,
skipping to change at page 11, line 16 skipping to change at page 11, line 25
EvidenceRecordWantBacks structure provides a flexible means of EvidenceRecordWantBacks structure provides a flexible means of
conveying an evidence record for different types of information. conveying an evidence record for different types of information.
EvidenceRecordWantBack ::= SEQUENCE EvidenceRecordWantBack ::= SEQUENCE
{ {
targetWantBack OBJECT IDENTIFIER, targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL evidenceRecord EvidenceRecord OPTIONAL
} }
EvidenceRecordWantBacks ::= EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1...MAX) OF EvidenceRecordWantBack SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
EvidenceRecordWantBacks is a SEQUENCE OF EvidenceRecordWantBack EvidenceRecordWantBacks is a SEQUENCE OF EvidenceRecordWantBack
structures. The targetWantBack field indicates the type of structures. The targetWantBack field indicates the type of
replyWantBack covered by the associated EvidenceRecord. The replyWantBack covered by the associated EvidenceRecord. The
evidenceRecord field, if present, contains an EvidenceRecord evidenceRecord field, if present, contains an EvidenceRecord
structure calculated over the replyWantBack indicated by the structure calculated over the replyWantBack indicated by the
targetWantBack field. There MUST be a one to one correspondence targetWantBack field. Where EvidenceRecordWantBacks is used, there
between other replyWantBack objects and objects in the MUST be a one to one correspondence between other replyWantBack
EvidenceRecordWantBacks collection. If a server does not have an objects and objects in the EvidenceRecordWantBacks collection. If a
EvidenceRecord for a particular replyWantBack object, an server does not have an EvidenceRecord for a particular replyWantBack
EvidenceRecordWantBack with the evidenceRecord field absent should be object, an EvidenceRecordWantBack with the evidenceRecord field
included in the EvidenceRecordWantBacks collection. absent should be included in the EvidenceRecordWantBacks collection.
5.6. Partial certification path 5.6. Partial certification path
The id-swb-partial-cert-path is an alternative to id-swb-best-cert- 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 path. This is the only OID defined in this document for which an
EvidenceRecord is not returned in the response. For efficiency, SCVP EvidenceRecord is not returned in the response. For efficiency, SCVP
servers that maintain evidence records for certification paths may servers that maintain evidence records for certification paths may
only do so for partial paths instead of maintaining one or more paths only do so for partial paths instead of maintaining one or more paths
for each end entity certificate. for each end entity certificate.
skipping to change at page 12, line 20 skipping to change at page 14, line 5
The signature on the SCVP response containing one or more ERS The signature on the SCVP response containing one or more ERS
structures must be verified using a public key trusted by the relying structures must be verified using a public key trusted by the relying
party. The response may contain trust anchors used to verify party. The response may contain trust anchors used to verify
interior layers of an ERS structure. The trust anchors are protected interior layers of an ERS structure. The trust anchors are protected
by the SCVP server's signature covering the response. The relying by the SCVP server's signature covering the response. The relying
party may elect to use the trust anchors conveyed in the response or 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 ignore the trust anchors in favor of trust anchors retrieved out of
band. Relying parties SHOULD ignore trust anchors contained in band. Relying parties SHOULD ignore trust anchors contained in
unsigned SCVP responses. 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.
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 14, line 22 skipping to change at page 15, line 22
[RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence [RFC4998] Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
Record Syntax (ERS)", RFC 4998, August 2007. Record Syntax (ERS)", RFC 4998, August 2007.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
Polk, "Server-Based Certificate Validation Protocol Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, December 2007. (SCVP)", RFC 5055, December 2007.
8.2. Informative References 8.2. Informative References
[I-D.ietf-ltans-ltap] [I-D.ietf-ltans-ltap]
Jerman-Blazic, A., "Long-term Archive Protocol (LTAP)", Jerman-Blazic, A., Sylvester, P., and C. Wallace, "Long-
draft-ietf-ltans-ltap-05 (work in progress), July 2007. term Archive Protocol (LTAP)", draft-ietf-ltans-ltap-06
(work in progress), February 2008.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
LTANS_SCVP_EXTENSION The following ASN.1 module defines object identifiers used to
identify six new forms of SCVP WantBacks and three new structures.
EvidenceRecordWantBack and EvidenceRecordWantBacks are used in
conjunction with the id-swb-ers-all WantBack to correlate evidence
records with WantBacks. EvidenceRecords is used in conjunction with
the id-swb-ers-revocation-info WantBack to return evidence records
for individual revocation information objects.
LTANS-SCVP-EXTENSION
{ iso(1) identified-organization(3) dod(6) internet(1) { iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers-scvp(5) security(5) mechanisms(5) ltans(11) id-mod(0) id-mod-ers-scvp(5)
id-mod-ers-scvp-v1(1) } id-mod-ers-scvp-v1(1) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
id-swb id-swb
skipping to change at page 15, line 45 skipping to change at page 17, line 43
EvidenceRecordWantBack ::= SEQUENCE EvidenceRecordWantBack ::= SEQUENCE
{ {
targetWantBack OBJECT IDENTIFIER, targetWantBack OBJECT IDENTIFIER,
evidenceRecord EvidenceRecord OPTIONAL evidenceRecord EvidenceRecord OPTIONAL
} }
EvidenceRecordWantBacks ::= EvidenceRecordWantBacks ::=
SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord
END END
Author's Address Author's Address
Carl Wallace Carl Wallace
Cygnacom Solutions Cygnacom Solutions
Suite 5200 Suite 5200
7925 Jones Branch Drive 7925 Jones Branch Drive
McLean, VA 22102 McLean, VA 22102
skipping to change at page 17, line 44 skipping to change at line 546
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 17 change blocks. 
54 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/