doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc5276.txt b/doc/rfc/rfc5276.txt
new file mode 100644
index 0000000..78bcfd8
--- /dev/null
+++ b/doc/rfc/rfc5276.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+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]
+