[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5276

Long-term Archive And Notary                                  C. Wallace
Services (LTANS)                                Orion Security Solutions
Internet-Draft                                        September 29, 2005
Expires: April 2, 2006


            Using SCVP to Convey Long-term Evidence Records
                    draft-ietf-ltans-ers-scvp-00.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 2, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

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



Wallace                   Expires April 2, 2006                 [Page 1]

Internet-Draft          Evidence Records via SCVP         September 2005


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Concept of Operations  . . . . . . . . . . . . . . . . . . . .  4
   3.  Requests . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Responses  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  WantBacks  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  Evidence record for a complete certification path  . . . .  9
     5.2.  Evidence record for a partial certification path . . . . .  9
     5.3.  Evidence record for a public key certificate . . . . . . . 10
     5.4.  Evidence record for a revocation information . . . . . . . 10
     5.5.  Evidence record for any replyWantBack  . . . . . . . . . . 10
     5.6.  Partial certification path . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   7.  Normative References . . . . . . . . . . . . . . . . . . . . . 12
   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Intellectual Property and Copyright Statements . . . . . . . . . . 16

























Wallace                   Expires April 2, 2006                 [Page 2]

Internet-Draft          Evidence Records via SCVP         September 2005


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.








Wallace                   Expires April 2, 2006                 [Page 3]

Internet-Draft          Evidence Records via SCVP         September 2005


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 April 2, 2006                 [Page 4]

Internet-Draft          Evidence Records via SCVP         September 2005


      - 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 April 2, 2006                 [Page 5]

Internet-Draft          Evidence Records via SCVP         September 2005


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.

   [NOTE: id-swb-partial-cert-path and id-swb-ers-partial-cert-path may
   not be necessary.  A client could achieve the same end by building a
   path to the issuer of an end entity certificate.]

   [NOTE: id-swb-pkc-cert is probably not applicable since the cert is
   returned in the response in a location other than the replyWantBack
   field.  An alternative OID could be defined that results in the
   certificate being returned as a replyWantBack that is the target of a



Wallace                   Expires April 2, 2006                 [Page 6]

Internet-Draft          Evidence Records via SCVP         September 2005


   corresponding ERS entry in the replyWantBack.]


















































Wallace                   Expires April 2, 2006                 [Page 7]

Internet-Draft          Evidence Records via SCVP         September 2005


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.  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-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 CertificateBundle returned in the id-
   swb-best-cert-path replyWantBack.

   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 April 2, 2006                 [Page 8]

Internet-Draft          Evidence Records via SCVP         September 2005


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-pkc-cert 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 April 2, 2006                 [Page 9]

Internet-Draft          Evidence Records via SCVP         September 2005


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 April 2, 2006                [Page 10]

Internet-Draft          Evidence Records via SCVP         September 2005


   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 April 2, 2006                [Page 11]

Internet-Draft          Evidence Records via SCVP         September 2005


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.

7.  Normative References

   [I-D.ietf-ltans-ers]
              Brandner, R., "Evidence Record Syntax (ERS)",
              draft-ietf-ltans-ers-02 (work in progress), April 2005.

   [I-D.ietf-ltans-ltap]
              Jerman-Blazic, A., "Long-term Archive Protocol (LTAP)",
              draft-ietf-ltans-ltap-00 (work in progress), July 2005.

   [I-D.ietf-pkix-scvp]
              Malpani, A., "Simple Certificate Validation Protocol



Wallace                   Expires April 2, 2006                [Page 12]

Internet-Draft          Evidence Records via SCVP         September 2005


              (SCVP)", draft-ietf-pkix-scvp-20 (work in progress),
              August 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.














































Wallace                   Expires April 2, 2006                [Page 13]

Internet-Draft          Evidence Records via SCVP         September 2005


Appendix A.  ASN.1 Module

   LTANS_SCVP_EXTENSION
   -- { iso(1) identified-organization(3) dod(6) internet(1)
   --   security(5) mechanisms(5) pkix(7) id-mod(0) TBD }

   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) pkix(7) id-mod(0) id-mod-ers(TBD) }

   id-swb-partial-cert-path        OBJECT IDENTIFIER ::= {id-swb 13 }

   id-swb-ers-pkc-cert             OBJECT IDENTIFIER ::= {id-swb 14 }
   id-swb-ers-best-cert-path       OBJECT IDENTIFIER ::= {id-swb 15 }
   id-swb-ers-partial-cert-path    OBJECT IDENTIFIER ::= {id-swb 16 }
   id-swb-ers-revocation-info      OBJECT IDENTIFIER ::= {id-swb 17 }
   id-swb-ers-all                  OBJECT IDENTIFIER ::= {id-swb 18 }

   EvidenceRecordWantBack ::= SEQUENCE
   {
       targetWantBack    OBJECT IDENTIFIER,
       evidenceRecord    EvidenceRecord OPTIONAL
   }

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

   END












Wallace                   Expires April 2, 2006                [Page 14]

Internet-Draft          Evidence Records via SCVP         September 2005


Author's Address

   Carl Wallace
   Orion Security Solutions
   Suite 300
   1489 Chain Bridge Road
   McLean, VA  22101

   Fax:   +1(703)917-0260
   Email: cwallace@orionsec.com









































Wallace                   Expires April 2, 2006                [Page 15]

Internet-Draft          Evidence Records via SCVP         September 2005


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 (2005).  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 2, 2006                [Page 16]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/