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

Versions: 00 01 02 03 04 05 06 07 08 RFC 5485

INTERNET DRAFT                                                  R. Housley
Intended Status: Informational                              Vigil Security
Expires: 21 February 2009                                   21 August 2008


             Digital Signatures on Internet-Draft Documents
             <draft-housley-internet-draft-sig-file-06.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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Abstract

   This document specifies the conventions for digital signatures on
   Internet-Drafts.  The Cryptographic Message Syntax (CMS) is used to
   create a detached signature, which is stored in a separate companion
   file so that no existing utilities are impacted by the addition of
   the digital signature.













Housley                                                         [Page 1]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


1.  Introduction

   This document specifies the conventions for storing a digital
   signature on Internet-Drafts.  The Cryptographic Message Syntax (CMS)
   [CMS] is used to create a detached signature.  The signature is
   stored in a separate companion file so that no existing utilities are
   impacted by the addition of the digital signature.

   At the time the IETF Secretariat posts the Internet-Draft in the
   repository, the digital signature is generated and posted as a
   companion file in the same repository.  The digital signature allows
   anyone to confirm that the contents of the Internet-Draft have not
   been altered since the time that the document was posted in the
   repository.

   The signature of the IETF Secretariat is intended to provide a
   straightforward way for anyone to determine whether a particular file
   contains the document that was made available by the IETF
   Secretariat.  The signing-time included by the IETF Secretariat
   provides the wall clock time; it is not intended to provide a trusted
   timestamp.

1.1.  Terminology

   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 RFC 2119 [STDWORDS].

1.2.  ASN.1

   The CMS uses Abstract Syntax Notation One (ASN.1) [X.680].  ASN.1 is
   a formal notation used for describing data protocols, regardless of
   the programming language used by the implementation.  Encoding rules
   describe how the values defined in ASN.1 will be represented for
   transmission.  The Basic Encoding Rules (BER) [X.690] are the most
   widely employed rule set, but they offer more than one way to
   represent data structures.  For example, definite length encoding and
   indefinite length encoding are supported.  This flexibility is not
   desirable when digital signatures are used.  As a result, the
   Distinguished Encoding Rules (DER) [X.690] were invented.  DER is a
   subset of BER that ensures a single way to represent a given value.
   For example, DER always employs definite length encoding.

2.  Internet-Draft Signature File

   All Internet-Draft file names begin with "draft-".  The next portion
   of the file name depends on the source of the document.  For example,
   documents from IETF working groups will have "ietf-" followed by the



Housley                                                         [Page 2]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


   working group abbreviation, and this is followed by a string that
   helps people figure out the subject of the document.

   All Internet-Draft file names end with a hyphen followed by a two
   digit version number and a suffix.  The suffix indicates the type of
   file.  A plain text file with a suffix of ".txt" is required.  Other
   formats may also be provided, and they employ the appropriate suffix
   for the file format.

   The companion signature file has exactly the same file name as the
   Internet-Draft, except that ".p7s" is added to the end.  This file
   name suffix conforms to the conventions in [MSG].  Here are a few
   example names:

      Internet-Draft: draft-ietf-example-widgets-03.txt
      Signature File: draft-ietf-example-widgets-03.txt.p7s

      Internet-Draft: draft-ietf-example-widgets-03.ps
      Signature File: draft-ietf-example-widgets-03.ps.p7s

      Internet-Draft: draft-housley-internet-draft-sig-file-00.txt
      Signature File: draft-housley-internet-draft-sig-file-00.txt.p7s

   The IETF Secretariat will post the signature file in the repository
   at the same time that the Internet-Draft is posted.

2.1.  Need for Canonicalization of Text Files

   In general, the content of the Internet-Draft is treated like a
   single octet string for the generation of the digital signature.
   Unfortunately, the plain text file requires canonicalization to avoid
   signature validation problems.  The primary concern is the manner in
   which different operating systems indicate the end of a line of text.
   Some systems use a single new-line character, other systems use the
   combination of the carriage-return character followed by a line-feed
   character, and other systems use fixed-length records padded with
   space characters.  For the digital signature to validate properly, a
   single convention must be employed.

2.2.  Text File Canonicalization

   The canonicalization procedure follows the conventions used for text
   files in the File Transfer Protocol (FTP) [FTP].  Such files must be
   supported by FTP implementations, so code reuse seems likely.

   The canonicalization procedure converts the data from its internal
   character representation to the standard 8-bit NVT-ASCII
   representation (see TELNET [TELNET]).  In accordance with the NVT



Housley                                                         [Page 3]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


   standard, the <CRLF> sequence MUST be used to denote the end of a
   line of text.  Using the standard NVT-ASCII representation means that
   data MUST be interpreted as 8-bit bytes.

   Trailing space characters MUST NOT appear on a line of text.  That
   is, the space character must not be followed by the <CRLF> sequence.
   Thus, a blank line is represented solely by the <CRLF> sequence.

   The form-feed nonprintable character (0x0C) is expected in Internet-
   Drafts.  Other nonprintable characters, such as tab and backspace,
   are not expected, but they do occur.  For robustness, any
   nonprintable characters (ones outside the range 0x20 to 0x7E) MUST
   NOT be changed in any way not covered by the rules for end-of-line
   handling in the previous paragraph.

   Trailing blank lines MUST NOT appear at the end of the file.  That
   is, the file must not end with multiple consecutive <CRLF> sequences.

   Any end-of-file marker used by an operating system is not considered
   to be part of the file content.  When present, such end-of-file
   markers MUST NOT be processed by the digital signature algorithm.

   Note: This text file canonicalization procedure is consistent with
   the ASCII NVT Definition offered in Appendix B of RFC 5198 [UFNI].

2.3.  Canonicalization of Other File Formats

   No canonicalization is needed for file formats other than plain text
   files.  Other file formats are treated as a simple sequence of octets
   by the digital signature algorithm.

3.  CMS Profile

   CMS is used to construct the detached signature of the Internet-
   Draft.  The CMS ContentInfo content type MUST always be present, and
   it MUST encapsulate the CMS SignedData content type.  Since a
   detached signature is being created, the CMS SignedData content type
   MUST NOT encapsulate the Internet-Draft.  The CMS detached signature
   is summarized by:

      ContentInfo {
        contentType          id-signedData, -- (1.2.840.113549.1.7.2)
        content              SignedData
      }







Housley                                                         [Page 4]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


      SignedData {
        version              CMSVersion, -- Always set to 3
        digestAlgorithms     DigestAlgorithmIdentifiers,
        encapContentInfo     EncapsulatedContentInfo,
        certificates         CertificateSet, -- Secretariat certificate(s)
        crls                 CertificateRevocationLists, -- Optional
        signerInfos          SET OF SignerInfo -- Only one signer
      }

      SignerInfo {
        version              CMSVersion, -- Always set to 3
        sid                  SignerIdentifier,
        digestAlgorithm      DigestAlgorithmIdentifier,
        signedAttrs          SignedAttributes, -- Always present
        signatureAlgorithm   SignatureAlgorithmIdentifier,
        signature            SignatureValue,
        unsignedAttrs        UnsignedAttributes -- Optional
      }

      EncapsulatedContentInfo {
        eContentType         id-ct-asciiTextWithCRLF,
                                         -- (1.2.840.113549.1.9.16.1.27)
        eContent             OCTET STRING  -- Always absent
      }

3.1.  ContentInfo

   The CMS requires the outer-most encapsulation to be ContentInfo
   [CMS].  The fields of ContentInfo are used as follows:

      contentType
         indicates the type of the associated content, and for the
         detached Internet-Draft signature file, the encapsulated type
         is always SignedData, so the id-signedData
         (1.2.840.113549.1.7.2) object identifier MUST be present in
         this field.

      content
         holds the content, and for the detached Internet-Draft
         signature file, the content is always a SignedData content.

3.2.  SignedData

   The SignedData content type [CMS] contains the signature of the
   Internet-Draft and information to aid in the validation of that






Housley                                                         [Page 5]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


   signature.  The fields of SignedData are used as follows:

      version
         is the syntax version number, and for this specification, the
         version number MUST be set to 3.

      digestAlgorithms
         is a collection of one-way hash function identifiers.  It MUST
         contain the identifier used by the IETF Secretariat to generate
         the digital signature.  See the discussion of digestAlgorithm
         in Section 3.2.1.

      encapContentInfo
         is the signed content, including a content type identifier.
         Since a detached signature is being created, it does not
         encapsulate the Internet-Draft.  The use of the
         EncapsulatedContentInfo type is discussed further in Section
         3.2.2.

      certificates
         is an optional collection of certificates.  It SHOULD include
         the X.509 certificate needed to validate the digital signature
         value.  Certification Authority (CA) certificates and end
         entity certificates MUST conform to the certificate profile
         specified in [PKIX1].

      crls
         is an optional collection of certificate revocation lists
         (CRLs).  It SHOULD NOT include any CRLs; however, any CRLs that
         are present MUST conform to the CRL profile specified in
         [PKIX1].

      signerInfos
         is a collection of per-signer information, and for this
         specification, each item in the collection must represent the
         IETF Secretariat.  More than one SignerInfo MAY appear to
         facilitate transitions between keys or algorithms.  The use of
         the SignerInfo type is discussed further in Section 3.2.1.

3.2.1.  SignerInfo

   The IETF Secretariat is represented in the SignerInfo type.  The
   fields of SignerInfo are used as follows:

      version
         is the syntax version number.  In this specification, the
         version MUST be set to 3.




Housley                                                         [Page 6]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


      sid
         identifies the IETF Secretariat's public key.  In this
         specification, the subjectKeyIdentifier alternative is always
         used, which identifies the public key directly.  This
         identifier MUST match the value included in the
         subjectKeyIdentifier certificate extension in the IETF
         Secretariat's X.509 certificate.

      digestAlgorithm
         identifies the one-way hash function, and any associated
         parameters, used by the IETF Secretariat to generate the
         digital signature.

      signedAttrs
         is an optional set of attributes that are signed along with the
         content.  The signedAttrs are optional in the CMS, but
         signedAttrs is required by this specification.  The SET OF
         Attribute must be encoded with the distinguished encoding rules
         (DER) [X.690].  Section 3.2.3 of this document lists the signed
         attributes that MUST be included in the collection.  Other
         signed attributes MAY also be included.

      signatureAlgorithm
         identifies the digital signature algorithm, and any associated
         parameters, used by the IETF Secretariat to  generate the
         digital signature.

      signature
         is the digital signature value generated by the IETF
         Secretariat.

      unsignedAttrs
         is an optional set of attributes that are not signed.  Unsigned
         attributes are usually omitted; however, the unsigned
         attributes MAY hold a trusted timestamp generated in accordance
         with [TSP].  Section 2.2.4 of [TSP] provides more information
         about this unsigned attribute.

3.2.2.  EncapsulatedContentInfo

   The EncapsulatedContentInfo structure contains a content type
   identifier.  Since a detached signature is being created, it does not
   encapsulate the Internet-Draft.  The fields of
   EncapsulatedContentInfo are used as follows:

      eContentType
         is an object identifier that uniquely specifies the content
         type.  The content type associated with the plain text file



Housley                                                         [Page 7]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


         MUST be id-ct-asciiTextWithCRLF.  Other file formats may also
         be posted, and the appropriate content type for each format is
         discussed in Section 4.  Additional file formats can be added
         if the Internet community chooses.

      eContent
         is optional.  When an encapsulated signature is generated, the
         content to be signed is carried in this field.  Since a
         detached signature is being created, eContent MUST be absent.

3.2.3.  Signed Attributes

   The IETF Secretariat MUST digitally sign a collection of attributes
   along with the Internet-Draft.  Each attribute in the collection MUST
   be DER-encoded.  The syntax for attributes is defined in [X.501], and
   the X.500 Directory provides a rich attribute syntax.  A very simple
   subset of this syntax is used extensively in [CMS], where
   ATTRIBUTE.&Type and ATTRIBUTE.&id are the only parts of the ATTRIBUTE
   class that are employed.

   Each of the attributes used with this CMS profile has a single
   attribute value.  Even though the syntax is defined as a SET OF
   AttributeValue, there MUST be exactly one instance of AttributeValue
   present.

   The SignedAttributes syntax within signerInfo is defined as a SET OF
   Attribute.  The SignedAttributes MUST include only one instance of
   any particular attribute.

   The IETF Secretariat MUST include the content-type, message-digest,
   and signing-time attributes.  The IETF Secretariat MAY also include
   the binary-signing-time signed attribute as well as any other
   attribute that is deemed appropriate.  The intent is to allow
   additional signed attributes to be included if a future need is
   identified.  This does not cause an interoperability concern because
   unrecognized signed attributes are ignored at verification.

3.2.3.1.  Content-Type Attribute

   A content-type attribute is required to contain the same object
   identifier as the content type contained in the
   EncapsulatedContentInfo.  The appropriate content type for each
   format is discussed in Section 4.  The IETF Secretariat MUST include
   a content-type attribute containing the appropriate content type.
   Section 11.1 of [CMS] defines the content-type attribute.






Housley                                                         [Page 8]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


3.2.3.2.  Message-Digest Attribute

   The IETF Secretariat MUST include a message-digest attribute, having
   as its value the output of a one-way hash function computed on the
   Internet-Draft that is being signed.  Section 11.2 of [CMS] defines
   the message-digest attribute.

3.2.3.3.  Signing-Time Attribute

   The IETF Secretariat MUST include signing-time attribute, specifying
   the time, based on the local system clock, at which the digital
   signature was applied to the Internet-Draft.  Section 11.3 of [CMS]
   defines the content-type attribute.

3.2.3.4.  Binary-Signing-Time Attribute

   The IETF Secretariat MAY include a binary-signing-time attribute,
   specifying the time at which the digital signature was applied to the
   Internet-Draft.  If present, the time that is represented MUST match
   the time represented in the signing-time attribute.  The binary-
   signing-time attribute is defined in [BinTime].

3.2.4.  Unsigned Attributes

   Unsigned attributes are usually omitted.  However, an unsigned
   attribute MAY hold a trusted timestamp generated in accordance with
   [TSP].  The idea is to time-stamp the IETF Secretariat digital
   signature to prove that it was created before a given time.  If the
   IETF Secretariat's certificate is revoked the time stamp allows a
   verifier to know whether the signature was created before or after
   the revocation date.  Appendix A of [TSP] defines the signature time-
   stamp attribute that can be used to time-stamp a digital signature.

4.  Content Types

   This section lists the content types that are used in this
   specification.  The eContentType field as described in Section 3.2.2
   contains a content type identifier, and the same value appears in the
   content-type attribute as described in Section 3.2.3.1.












Housley                                                         [Page 9]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


   The following table lists the file formats and the associated content
   type.

      File Format                        Content Type
      -----------                        ------------
      Plain text                         id-ct-asciiTextWithCRLF
      Extensible Markup Language (XML)   id-ct-xml
      Portable Document Format (PDF)     id-ct-pdf
      PostScript                         id-ct-postscript

   The object identifiers associated with the content types listed in
   the above table are:

      id-ct  OBJECT IDENTIFIER  ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) 1 }

      id-ct-asciiTextWithCRLF  OBJECT IDENTIFIER  ::= { id-ct 27 }

      id-ct-xml  OBJECT IDENTIFIER  ::= { id-ct 28 }

      id-ct-pdf  OBJECT IDENTIFIER  ::= { id-ct 29 }

      id-ct-postscript  OBJECT IDENTIFIER  ::= { id-ct 30 }

5.  Security Considerations

   The IETF Secretariat MUST protect its private key.  The use of a
   hardware security module is RECOMMENDED because compromise of the
   IETF Secretariat's private key permits masquerade.

   The generation of a public/private key pair for signature operations
   relies on random number generation.  The use of an inadequate pseudo-
   random number generator (PRNG) can result in little or no security.
   An attacker may find it much easier to reproduce the PRNG environment
   that produced the key pair, searching the resulting small set of
   possibilities, rather than brute force searching the whole private
   key space.  The generation of quality random numbers is difficult,
   but [RANDOM] offers important guidance in this area.

   The IETF Secretariat should be aware that cryptographic algorithms
   become weaker with time.  As new cryptoanalysis techniques are
   developed and computing performance improves, the work factor to
   break a particular digital signature algorithm or one-way hash
   function will be reduced.  Therefore, it SHOULD be possible to
   migrate these algorithms.  That is, the IETF Secretariat SHOULD be
   prepared for the supported algorithms to change over time.

   The IETF Secretariat must take care to use the correct time in



Housley                                                        [Page 10]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


   signing-time and binary-signing-time attributes.  The inclusion of a
   compatible date within the Internet-Draft by the authors and the
   signing time attributes by the IETF Secretariat provides confidence
   about the date that the Internet-Draft was posted to the repository.

6.  Deployment and Operational Considerations

   The private key used to generate the IETF Secretariat signature ought
   to be stored in a hardware security module to provide protection from
   unauthorized disclosure.  While the hardware security module will be
   operated by the IETF Secretariat, it ought to be owned by the IETF
   Trust.  Accordingly, the Trustees of the IETF Trust will designate an
   appropriate certification authority to issue a certificate to the
   IETF Secretariat, and they will approve any procedures used by the
   IETF Secretariat for signing documents consistent with this
   specification.

7.  Design Rationale

   A detached signature is used for all file formats.  Some file
   formats, such as PDF and XML, have file-format-specific ways of
   handling digital signatures.  These file-format-specific approaches
   are not used for two reasons.  First, a single way to sign Internet-
   Drafts will ease implementation by the IETF Secretariat.  Second, if
   the author includes a signature using one of these file-format-
   specific approaches, the Secretariat signature does not harm it in
   any way.

   File names are the means linking the detached signature to the signed
   document.  A CMS signed attribute could have been specified to
   include another form of linkage, and this could be added in the
   future.  At this point in time, it is important to support signature
   validation of expired Internet-Drafts that are obtained from non-IETF
   repositories.  Therefore, the appropriate value for such a signed
   attribute is unclear.  This specification allows an Internet-Draft
   and companion signature file to be stored anywhere without hindering
   signature validation.

8.  References

8.1.  Normative References

   [CMS]       Housley, R., "Cryptographic Message Syntax (CMS)",
               RFC 3852, July 2004.







Housley                                                        [Page 11]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


   [PKIX1]     Cooper, D., Santesson, s., Farrell, S., Boeyen, s.,
               Housley, R., and W. Polk, "Internet X.509 Public Key
               Infrastructure Certificate and Certificate Revocation
               List (CRL) Profile", RFC 5280, May 2008.

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

   [X.680]     ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
               Information technology - Abstract Syntax Notation One
               (ASN.1):  Specification of basic notation.

   [X.690]     ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
               Information technology - ASN.1 encoding rules: Specification
               of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
               and Distinguished Encoding Rules (DER).

8.2.  Informative References

   [BinTime]   Housley, R., "BinaryTime: An Alternate Format for
               Representing Date and Time in ASN.1", RFC 4049,
               April 2005.

   [FTP]       Postel, J. and J. Reynolds, "File Transfer Protocol",
               STD 9, RFC 959, October 1985.

   [MSG]       Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
               Extensions (S/MIME) Version 3.1 Message Specification",
               RFC 3851, July 2004.

   [OpenSSL]   http://www.openssl.org/

   [RANDOM]    Eastlake, D., Schiller, J., and S. Crocker, "Randomness
               Recommendations for Security", BCP 106, RFC 4086,
               June 2005.

   [TELNET]    Postel, J. and J. Reynolds, "Telnet Protocol
               Specification", STD 8, RFC 854, May 1983.

   [TSP]       Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
               "Internet X.509 Public Key Infrastructure Time-Stamp
               Protocol (TSP)", RFC 3161, August 2001.

   [UFNI]      J. Klensin, J. and M. Padlipsky, "Unicode Format for
               Network Interchange", RFC 5198, March 2008.






Housley                                                        [Page 12]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


   [X.501]     ITU-T Recommendation X.501: Information Technology -
               Open Systems Interconnection - The Directory: Models,
               1993.

9.  Acknowledgements

   The idea for the Internet-Draft signature file came from a discussion
   with Scott Bradner at IETF 69 in Chicago.  Many helpful suggestions
   came from Jim Schaad.

10.  IANA Considerations

   None.

   {{{ RFC Editor: Please remove this section prior to publication. }}}

Appendix: A

   OpenSSL 0.9.9 [OpenSSL] includes an implementation of CMS.  The
   following command line can be used to verify an Internet-Draft
   signature:

      openssl cms -verify -CAfile <cert-file> -content <internet-draft> /
           -inform DER -in <p7s-file> -out /dev/null

   The arguments need to be provided as follows:

      <cert-file>
         the name of the file containing the trust anchor, which is
         typically the self-signed certificate of the certification
         authority that issued a certificate to the IETF Secretariat.

      <internet-draft>
         the name of the file containing the signed Internet-Draft.

      <p7s-file>
         the name of the file containing the detached signature that was
         generated in accordance with this specification.

Author's Address

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA

   EMail: housley@vigilsec.com



Housley                                                        [Page 13]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


Copyright and IPR Statements

   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 translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   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.

   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.



Housley                                                        [Page 14]

INTERNET DRAFT    Digital Signatures on Internet-Drafts        June 2008


   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.














































Housley                                                        [Page 15]


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