GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5276

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
 the purpose 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 objects 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
 document are to be interpreted as described in [RFC2119].

Wallace Standards Track [Page 3] RFC 5276 Evidence Records via SCVP August 2008

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 Object
 Identifiers (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:
 o  end entity certificates.
 o  certification paths containing an end entity certificate up to a
    trust anchor.
 o  certification paths containing an intermediate certificate up to a
    trust anchor.
 o  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
 the 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:
 o  Client retrieves a signed archived data object from an LTA using
    LTAP.

Wallace Standards Track [Page 4] RFC 5276 Evidence Records via SCVP August 2008

 o  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.
 o  SCVP server returns a response with status as of the time of
    interest and includes requested evidence records.
 o  Client processes the SCVP request, determines the status, and
    verifies the evidence records.
 o  Client verifies signatures in the archived data object using the
    validated signer's certificate.

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:
 o  id-swb-ers-best-cert-path
 o  id-swb-ers-partial-cert-path
 o  id-swb-ers-pkc-cert
 o  id-swb-ers-revocation-info
 o  id-swb-ers-all
 Additionally, id-swb-partial-cert-path is defined to permit clients
 to request a partial certification path consisting of the
 certification authority (CA) that 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 [RFC4998]) 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.

Wallace Standards Track [Page 5] RFC 5276 Evidence Records via SCVP August 2008

 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 could
 include the following three replyWantBack OIDs: id-swb-best-cert-
 path, id-swb-pkc-revocation-info, and id-swb-ers-all.

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 and id-swb-ers-revocation-
 info, the evidence record MUST be calculated over the value of the
 value field in the corresponding replyWantBack; the tag and length
 bytes are not covered by the evidence record.  The targets for the
 id-swb-ers-pkc-cert and id-swb-ers-revocation-info replyWantBacks are
 described below.  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 MUST be calculated over the value of the cert field in the
 CertReply object.  For id-swb-ers-revocation-info, a sequence of
 evidence records is returned.  Each revocation information object
 contained in the id-swb-pkc-revocation-info replyWantBack is covered
 by an evidence record in the id-swb-ers-revocation-info
 replyWantBack.  A single evidence record may cover multiple
 revocation information objects.  The correct evidence record can be
 identified by locating the hash of the revocation information object
 in the first initial timestamp of the evidence record.
 If the server cannot return an EvidenceRecord for the requested
 information item, 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.

5. WantBacks

 The following sections describe each WantBack defined in this
 document.  Each WantBack for an evidence record requires a
 corresponding WantBack for the object covered by the evidence record
 to be present in the request.  Upon receipt of a request missing the

Wallace Standards Track [Page 6] RFC 5276 Evidence Records via SCVP August 2008

 corresponding WantBack for the object covered by a requested evidence
 record, the server MUST indicate wantBackUnsatisfied in the
 ReplyStatus.  Clients MAY ignore evidence record WantBacks when the
 WantBack for the corresponding object is not present.

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
 MUST be 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-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.

Wallace Standards Track [Page 7] RFC 5276 Evidence Records via SCVP August 2008

 By maintaining an evidence record for a partial certification path,
 SCVP servers can achieve greater storage efficiency.

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-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 Revocation Information

 The id-swb-ers-revocation-info OID is used to request evidence
 records 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.  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
 information.  Revocation information may be provided in the form of
 CRLs or Online Certificate Status Protocol (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 the replyWantBacks field.  Since id-swb-ers-
 all can result in the return of multiple evidence records in the

Wallace Standards Track [Page 8] RFC 5276 Evidence Records via SCVP August 2008

 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.
 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 covered by the associated EvidenceRecord.  The
 evidenceRecord field, if present, contains an EvidenceRecord
 structure calculated over the replyWantBack indicated by the
 targetWantBack field.  Where EvidenceRecordWantBacks is used, 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 a 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-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 Standards Track [Page 9] RFC 5276 Evidence Records via SCVP August 2008

6. Security Considerations

 For security considerations specific to SCVP, see [RFC5055].  For
 security considerations specific to ERS, see [RFC4998].
 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.

7. References

7.1. Normative References

 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC4998]     Gondrom, T., Brandner, R., and U. Pordesch, "Evidence
               Record Syntax (ERS)", RFC 4998, August 2007.
 [RFC5055]     Freeman, T., Housley, R., Malpani, A., Cooper, D., and
               W. Polk, "Server-Based Certificate Validation Protocol
               (SCVP)", RFC 5055, December 2007.

7.2. Informative References

 [LTANS-LTAP]  Jerman-Blazic, A., Sylvester, P., and C. Wallace,
               "Long-term Archive Protocol (LTAP)", Work in Progress,
               February 2008.

Wallace Standards Track [Page 10] RFC 5276 Evidence Records via SCVP August 2008

Appendix A. ASN.1 Module

 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)
    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
 }

Wallace Standards Track [Page 11] RFC 5276 Evidence Records via SCVP August 2008

 EvidenceRecordWantBacks ::=
     SEQUENCE SIZE (1..MAX) OF EvidenceRecordWantBack
 EvidenceRecords ::= SEQUENCE SIZE (1..MAX) OF EvidenceRecord
 END

Author's Address

 Carl Wallace
 Cygnacom Solutions
 Suite 5200
 7925 Jones Branch Drive
 McLean, VA  22102
 EMail: cwallace@cygnacom.com

Wallace Standards Track [Page 12] RFC 5276 Evidence Records via SCVP August 2008

Full Copyright Statement

 Copyright (C) The IETF Trust (2008).
 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.

Wallace Standards Track [Page 13]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5276.txt · Last modified: 2008/08/11 22:35 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki