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

Versions: 00 01

Long-term Archive And Notary                                  C. Wallace
Services (LTANS)                                      Cygnacom Solutions
Internet-Draft                                          October 23, 2006
Expires: April 26, 2007


         Infrastructure Support for Retention of PKI Artifacts
                 draft-ietf-ltans-pki-retention-01.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 26, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   In most PKIs, directory servers are used to provide current
   certificates and revocation information to relying parties.  In
   situations where certificates must be validated relative to a time in
   the past, relying parties often have no means of obtaining the
   necessary PKI artifacts.  This specification defines several
   directory attributes to support validation using historical PKI
   artifacts.




Wallace                  Expires April 26, 2007                 [Page 1]


Internet-Draft           PKI Artifact Retention             October 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3
   2.  Concept of Operations  . . . . . . . . . . . . . . . . . . . .  4
   3.  Object classes . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Public key certificates  . . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Appendix A.  ASN.1 Module  . . . . . . . . . . . . . . . . . . . .  9
   Appendix B.  Revocation information  . . . . . . . . . . . . . . . 10
     B.1.  Historical CRLs  . . . . . . . . . . . . . . . . . . . . . 10
     B.2.  Entry Revocation Publication extension . . . . . . . . . . 11
     B.3.  Historical CRL issuance extension  . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14

































Wallace                  Expires April 26, 2007                 [Page 2]


Internet-Draft           PKI Artifact Retention             October 2006


1.  Introduction

   Digital signatures are frequently verified using public key
   infrastructure (PKI) artifacts such as public key certificates and
   certificate revocation lists (CRLs).  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.

   The "Standard Certificate Validation Protocol" (SCVP) [I-D.ietf-pkix-
   scvp] defines a means of delegating certification path construction
   and/or validation to a server, including the ability to request the
   server to perform the operations relative to a time in the past.  The
   "Evidence Record Syntax" (ERS) [I-D.ietf-ltans-ers] defines
   structures 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.  "Using SCVP
   to Convey Evidence Records" [I-D.ietf-ltans-ers-scvp] defines a means
   of using SCVP to retrieve evidence records covering historical PKI
   artifacts.

   Directory servers are frequently used to make PKI artifacts available
   for use by public key-enabled applications.  However, in many PKIs,
   artifacts are removed from the directory when the artifact is updated
   by a newer version or the artifact expires.  This document describes
   a means of using LDAP or X.500 directory servers to retrieve
   historical PKI artifacts and, optionally, associated evidence
   records.

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                  Expires April 26, 2007                 [Page 3]


Internet-Draft           PKI Artifact Retention             October 2006


2.  Concept of Operations

   Public key-enabled applications build and validate certification
   paths in support of functions including digital signature
   verification and public key encryption.  In many cases, the materials
   used to validate a certification path are available via an X.500 or
   LDAP directory in accord with the schema defined in [RFC2587].  For
   many reasons, including size constraints on the server and
   performance impact on relying parties, directories usually contain
   PKI artifacts that are current, i.e., non-expired and most recent.
   Applications requiring access to historical PKI artifacts, i.e., not
   the most recent and possibly expired, are forced to rely upon other
   mechanisms.  This document defines an object class and a set of
   directory attributes that complement those defined in [RFC2587] for
   the purpose of making historical PKI artifacts available.




































Wallace                  Expires April 26, 2007                 [Page 4]


Internet-Draft           PKI Artifact Retention             October 2006


3.  Object classes

   Two object classes are defined for historical certificates and CRLs:
   historicalPKIEntity and historicalCRLDistributionPoint.  These
   auxiliary object classes MAY be used to represent entities associated
   with historical PKI artifacts.

   historicalPKIEntity OBJECT-CLASS ::=
   {
       SUBCLASS OF {top}
       KIND auxiliary
       MAY CONTAIN {historicalCertificate}
       ID TBD
   }
   historicalCRLDistributionPoint OBJECT-CLASS ::=
   {
       SUBCLASS OF {top}
       KIND auxiliary
       MAY CONTAIN {historicalCRL}
       ID TBD
   }


   This specification differs from [RFC2587] by not defining separate
   object classes or attributes to delineate between end entities and
   certification authorities.

























Wallace                  Expires April 26, 2007                 [Page 5]


Internet-Draft           PKI Artifact Retention             October 2006


4.  Public key certificates

   Public key certificates are digitally signed.  As such, certificates
   are subject to the same concerns as described for digitally signed
   forms, contracts, etc. in [I-D.ietf-ltans-ers].  To address these
   concerns, the integrity of public key certificates can be protected
   by generating and maintaining an evidence record covering the
   certificate.  A certificate and an evidence record can be bound
   together using the structure defined below.  Certificates are defined
   in [RFC3280] and evidence records are defined in [I-D.ietf-ltans-
   ers].

   HistoricalCertificate ::= SEQUENCE
   {
       certificate       Certificate,
       evidenceRecord    EvidenceRecord OPTIONAL
   }


   HistoricalCertificates can be made available via an X.500 or LDAP
   directory using the following attribute.  When a certificate is to be
   removed from a directory due to replacement or due to expiration, it
   MAY be removed from the userCertificate or cACertificate attribute
   and it SHOULD be added to the historicalCertificate attribute.  An
   evidence record for the certificate MAY be requested at that time or
   at a later time.

   historicalCertificate ATTRIBUTE ::=
   {
       WITH SYNTAX HistoricalCertificate
       EQUALITY MATCHING RULE historicalCertificateExactMatch,
       ID TBD
   }


















Wallace                  Expires April 26, 2007                 [Page 6]


Internet-Draft           PKI Artifact Retention             October 2006


5.  Security Considerations

   Since the information stored in the attributes defined in this
   specification are signed, no additional integrity service is
   required.

   Security considerations with respect to retrieval, addition, deletion
   and modification of the information supported by this schema
   definition are addressed in [RFC2559].

   The timing of the application or update of evidence records is a
   matter of local policy.  Security considerations associated with
   evidence records are described in [I-D.ietf-ltans-ers].






































Wallace                  Expires April 26, 2007                 [Page 7]


Internet-Draft           PKI Artifact Retention             October 2006


6.  References

6.1.  Normative References

   [I-D.ietf-ltans-ers]
              Brandner, R., "Evidence Record Syntax (ERS)",
              draft-ietf-ltans-ers-07 (work in progress), May 2006.

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

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

6.2.  Informative References

   [I-D.ietf-ltans-ers-scvp]
              Wallace, C., "Using SCVP to Convey Long-term Evidence
              Records", draft-ietf-ltans-ers-scvp-01 (work in progress),
              May 2006.

   [I-D.ietf-pkix-scvp]
              Malpani, A., "Server-based Certificate Validation Protocol
              (SCVP)", draft-ietf-pkix-scvp-27 (work in progress),
              June 2006.

   [RFC2559]  Boeyen, S., Howes, T., and P. Richard, "Internet X.509
              Public Key Infrastructure Operational Protocols - LDAPv2",
              RFC 2559, April 1999.

   [RFC2587]  Boeyen, S., Howes, T., and P. Richard, "Internet X.509
              Public Key Infrastructure LDAPv2 Schema", RFC 2587,
              June 1999.
















Wallace                  Expires April 26, 2007                 [Page 8]


Internet-Draft           PKI Artifact Retention             October 2006


Appendix A.  ASN.1 Module

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

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

   IMPORTS

   Certificate, CertificateList, Time
       FROM PKIX1Explicit88
           { iso(1) identified-organization(3) dod(6)
               internet(1) security(5) mechanisms(5) pkix(7)
               mod(0) pkix1-explicit(18) }

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

   HistoricalCertificate ::= SEQUENCE
   {
       certificate       Certificate,
       evidenceRecord    EvidenceRecord OPTIONAL
   }

   HistoricalCRL ::= SEQUENCE
   {
       crl               CertificateList,
       evidenceRecord    EvidenceRecord OPTIONAL
   }

   EntryRevocationPublication ::= Time
   HistoricalCRLIssuance ::= Time

   END













Wallace                  Expires April 26, 2007                 [Page 9]


Internet-Draft           PKI Artifact Retention             October 2006


Appendix B.  Revocation information

   Preservation of revocation information is more complicated than
   preservation of certificates due, primarily, to the volume of
   revocation information generated in most PKIs, i.e., CRLs are
   generated more frequently than certificates and are often much
   larger.  CRLs are signed and the signatures require preservation.
   However, the number of CRLs makes preservation difficult and
   complicates validation operations for relying parties.  A cumulative
   CRL provides a better target for preservation.  However, cumulative
   CRLs introduce additional processing rules.  To account for the
   HoldInstruction extension, all entries on a CRL must be reviewed, the
   entries applicable to a certificate sorted and the time of interest
   compared to the sorted list to determine if the certificate was on
   hold at that time.

   X.509 specifies a the expiredCertsOnCRL CRL extension, that is not
   present in [RFC3280], to indicate that the CRL contains expired
   certificates.  The extension is expressed as a GeneralizedTime value
   that provides the time at or since which certificates may have
   expired but will still appear on the CRL, i.e., certificates that
   expired before that time do not appear on the CRL.  Relying parties
   using a CRL of this sort must recognize that the time of interest for
   a path validation operation may fall outside the thisUpdate/
   nextUpdate period of a cumulative CRL.  The following section
   describes a variation on the X.509 CumulativeCRL extension that
   preserves the property where thisUpdate is less than or equal to the
   time of interest and nextUpdate is greater than or equal to the time
   of interest.

B.1.  Historical CRLs

   To avoid preserving every CRL instance generated within a PKI, an
   historical CRL can be generated and maintained.  An historical CRL is
   a CRL with the following properties:

      - The thisUpdate field is fixed and contains the time
      corresponding to the instantiation of the CA(s) covered by the
      CRL.

      - Entries optionally include an extension indicating the
      thisUpdate value from the first CRL on which the entry appeared.

      - The CRL structure is optionally associated with an
      EvidenceRecord.

   Historical CRLs are defined as follows.




Wallace                  Expires April 26, 2007                [Page 10]


Internet-Draft           PKI Artifact Retention             October 2006


   HistoricalCRL ::= SEQUENCE
   {
       crl               CertificateList,
       evidenceRecord    EvidenceRecord OPTIONAL
   }


   CRL issuers need not generate an historical CRL upon each CRL
   issuance.  Historical CRLs can be generated on a less frequent basis
   since certification path validation operations relative to the
   current time can be serviced using conventional CRLs.  When an
   historical CRL is generated, the thisUpdate time MUST NOT change from
   the value in the previous historical CRL.  The new CRL MUST replace
   the previous historical CRL in the historicalCRL directory attribute.
   The thisUpdate value in the first historical CRL issued by a CRL
   issuer SHOULD be set to the earliest notBefore value from the set of
   certificates issued by the CAs covered by the CRL.  After a CA no
   longer needs to issue CRLs, the final HistoricalCRL can be preserved
   by periodically updating the evidence record as described in
   [I-D.ietf-ltans-ers].

   For sake of simplicity, historical CRLs should not be indirect CRLs
   and should not be delta CRLs.  Where partitioned, historical CRLs
   MUST adhere to the partioning scheme used by the corresponding
   conventional CRLs.

B.2.  Entry Revocation Publication extension

   This CRL entry extension identifies the thisUpdate time from the CRL
   on which the entry first appeared.  If this extension is not present
   on the first entry in a CRL, the revocation publication value
   defaults to the thisUpdate value of the CRL.  On subsequent entries,
   if this extension is not present, the revocation publication value
   for the entry is the same as that for the preceding entry.  This
   extension is defined as follows:


   EntryRevocationPublication ::= Time


B.3.  Historical CRL issuance extension

   This optional CRL extension indicates the CRL is an historical CRL,
   i.e., the thisUpdate time is not based on the time of issuance.  The
   extension is used to convey the issuance time and is defined as
   follows:





Wallace                  Expires April 26, 2007                [Page 11]


Internet-Draft           PKI Artifact Retention             October 2006


   HistoricalCRLIssuance ::= Time


   If used by conforming CRL issuers, this extension MUST always be non-
   critical.

   HistoricalCRLs can be made available via an X.500 or LDAP directory
   using the following attribute.


   historicalCRL ATTRIBUTE ::=
   {
       WITH SYNTAX HistoricalCRL
       EQUALITY MATCHING RULE historicalCRLExactMatch,
       ID TBD
   }


   Historical CRLs are not intended to replace CRLs used by applications
   performing certification path validation relative to the current
   time.  CRL issuers should continue to publish conventional CRLs.






























Wallace                  Expires April 26, 2007                [Page 12]


Internet-Draft           PKI Artifact Retention             October 2006


Author's Address

   Carl Wallace
   Cygnacom Solutions
   Suite 5200
   7925 Jones Branch Drive
   McLean, VA  22102

   Email: cwallace@cygnacom.com










































Wallace                  Expires April 26, 2007                [Page 13]


Internet-Draft           PKI Artifact Retention             October 2006


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 (2006).  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 26, 2007                [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/