diff options
| -rw-r--r-- | doc/protocol/draft-ietf-tls-extractor-01.txt | 392 | ||||
| -rw-r--r-- | doc/protocol/draft-mavrogiannopoulos-rfc5081bis-00.txt | 504 |
2 files changed, 896 insertions, 0 deletions
diff --git a/doc/protocol/draft-ietf-tls-extractor-01.txt b/doc/protocol/draft-ietf-tls-extractor-01.txt new file mode 100644 index 0000000000..a992f2b24f --- /dev/null +++ b/doc/protocol/draft-ietf-tls-extractor-01.txt @@ -0,0 +1,392 @@ + + + +Network Working Group E. Rescorla +Internet-Draft Network Resonance +Intended status: Standards Track February 20, 2008 +Expires: August 23, 2008 + + + Keying Material Extractors for Transport Layer Security (TLS) + draft-ietf-tls-extractor-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 August 23, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2008). + +Abstract + + A number of protocols wish to leverage Transport Layer Security (TLS) + to perform key establishment but then use some of the keying material + for their own purposes. This document describes a general mechanism + for allowing that. + + + + + + + +Rescorla Expires August 23, 2008 [Page 1] + +Internet-Draft TLS Extractors February 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3 + 3. Binding to Application Contexts . . . . . . . . . . . . . . . . 3 + 4. Extractor Definition . . . . . . . . . . . . . . . . . . . . . 4 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 8.2. Informational References . . . . . . . . . . . . . . . . . 6 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 + Intellectual Property and Copyright Statements . . . . . . . . . . 7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rescorla Expires August 23, 2008 [Page 2] + +Internet-Draft TLS Extractors February 2008 + + +1. Introduction + + A number of protocols wish to leverage Transport Layer Security (TLS) + [RFC4346] or Datagram TLS (DTLS) [RFC4347] to perform key + establishment but then use some of the keying material for their own + purposes. A typical example is DTLS-SRTP [I-D.ietf-avt-dtls-srtp], + which uses DTLS to perform a key exchange and negotiate the SRTP + [RFC3711] protection suite and then uses the DTLS master_secret to + generate the SRTP keys. + + These applications imply a need to be able to extract keying material + (later called Exported Keying Material or EKM) from TLS/DTLS, and + securely agree on the upper-layer context where the keying material + will be used. The mechanism for extracting the keying material has + the following requirements: + + o Both client and server need to be able to extract the same EKM + value. + o EKM values should be indistinguishable from random by attackers + who don't know the master_secret. + o It should be possible to extract multiple EKM values from the same + TLS/DTLS association. + o Knowing one EKM value should not reveal any information about the + master_secret or about other EKM values. + + The mechanism described in this document is intended to fill these + requirements. + + +2. Conventions Used In This Document + + 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]. + + +3. Binding to Application Contexts + + In addition to extracting keying material, an application using the + keying material has to securely establish the upper-layer layer + context where the keying material will be used. The details of this + context depend on the application, but it could include things such + as algorithms and parameters that will be used with the keys, + identifier(s) for the endpoint(s) who will use the keys, + identifier(s) for the session(s) where the keys will be used, and the + lifetime(s) for the context and/or keys. At minimum, there should be + some mechanism for signalling that an extractor will be used. + + + + +Rescorla Expires August 23, 2008 [Page 3] + +Internet-Draft TLS Extractors February 2008 + + + This specification does not mandate a single mechanism for agreeing + on such context; instead, there are several possibilities that can be + used (and can complement each other). For example: + + o One important part of the context -- which application will use + the extracted keys -- is given by the disambiguating label string + (see Section 4). + o Information about the upper-layer context can be included in the + optional data after the extractor label (see Section 4). + o Information about the upper-layer context can be exchanged in TLS + extensions included in the ClientHello and ServerHello messages. + This approach is used in [DTLS-SRTP]. The handshake messages are + protected by the Finished messages, so once the handshake + completes, the peers will have the same view of the information. + Extensions also allow a limited form of negotiation: for example, + the TLS client could propose several alternatives for some context + parameters, and TLS server could select one of them. + o The upper-layer protocol can include its own handshake which can + be protected using the keys extracted from TLS. + + It is important to note that just embedding TLS messages in the + upper-layer protocol may not automatically secure all the important + context information, since the upper-layer messages are not covered + by TLS Finished messages. + + +4. Extractor Definition + + An extractor takes as input three values: + + o A disambiguating label string + o A per-association context value provided by the extractor using + application + o A length value + + It then computes: + + + PRF(master_secret, label, + SecurityParameters.client_random + + SecurityParameters.server_random + + context_value_length + context_value + )[length] + + The output is a pseudorandom bit string of length bytes generated + from the master_secret. + + Label values beginning with "EXPERIMENTAL" MAY be used for private + + + +Rescorla Expires August 23, 2008 [Page 4] + +Internet-Draft TLS Extractors February 2008 + + + use without registration. All other label values MUST be registered + via Specification Required as described by RFC 2434 [RFC2434]. Note + that extractor labels have the potential to collide with existing PRF + labels. In order to prevent this, labels SHOULD begin with + "EXTRACTOR". This is not a MUST because there are existing uses + which have labels which do not begin with this prefix. + + The context value allows the application using the extractor to mix + its own data with the TLS PRF for the extractor output. The context + value length is encoded as an unsigned 16-bit quantity (uint16) + representing the length of the context value. + + +5. Security Considerations + + Because an extractor produces the same value if applied twice with + the same label to the same master_secret, it is critical that two EKM + values generated with the same label be used for two different + purposes--hence the requirement for IANA registration. However, + because extractors depend on the TLS PRF, it is not a threat to the + use of an EKM value generated from one label to reveal an EKM value + generated from another label. + + +6. IANA Considerations + + IANA is requested to create (has created) a TLS Extractor Label + registry for this purpose. The initial contents of the registry are + given below: + + Value Reference + ----- ------------ + client finished [RFC4346] + server finished [RFC4346] + master secret [RFC4346] + key expansion [RFC4346] + client EAP encryption [RFC2716] + ttls keying material [draft-funk-eap-ttls-v0-01] + + Future values are allocated via RFC2434 Specification Required + policy. The label is a string consisting of printable ASCII + characters. IANA MUST also verify that one label is not a prefix of + any other label. For example, labels "key" or "master secretary" are + forbidden. + + + + + + + +Rescorla Expires August 23, 2008 [Page 5] + +Internet-Draft TLS Extractors February 2008 + + +7. Acknowledgments + + Thanks to Pasi Eronen for valuable comments and the contents of the + IANA section and Section 3. + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + +8.2. Informational References + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security", RFC 4347, April 2006. + + [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. + Norrman, "The Secure Real-time Transport Protocol (SRTP)", + RFC 3711, March 2004. + + [I-D.ietf-avt-dtls-srtp] + McGrew, D. and E. Rescorla, "Datagram Transport Layer + Security (DTLS) Extension to Establish Keys for Secure + Real-time Transport Protocol (SRTP)", + draft-ietf-avt-dtls-srtp-01 (work in progress), + November 2007. + + +Author's Address + + Eric Rescorla + Network Resonance + 2064 Edgewood Drive + Palo Alto, CA 94303 + USA + + Email: ekr@networkresonance.com + + + + + +Rescorla Expires August 23, 2008 [Page 6] + +Internet-Draft TLS Extractors February 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. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Rescorla Expires August 23, 2008 [Page 7] + diff --git a/doc/protocol/draft-mavrogiannopoulos-rfc5081bis-00.txt b/doc/protocol/draft-mavrogiannopoulos-rfc5081bis-00.txt new file mode 100644 index 0000000000..8a4d32e67d --- /dev/null +++ b/doc/protocol/draft-mavrogiannopoulos-rfc5081bis-00.txt @@ -0,0 +1,504 @@ + + + +Network Working Group N. Mavrogiannopoulos +Internet-Draft Independent +Updates: rfc5081 January 2008 +(if approved) +Intended status: Informational +Expires: July 4, 2008 + + + Using OpenPGP Keys for Transport Layer Security (TLS) Authentication + draft-mavrogiannopoulos-rfc5081bis-00 + +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 July 4, 2008. + +Copyright Notice + + Copyright (C) The IETF Trust (2008). + +Abstract + + This memo proposes extensions to the Transport Layer Security (TLS) + protocol to support the OpenPGP key format. The extensions discussed + here include a certificate type negotiation mechanism, and the + required modifications to the TLS Handshake Protocol. + + + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 1] + +Internet-Draft Using OpenPGP Keys January 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Changes to the Handshake Message Contents . . . . . . . . . . . 3 + 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 4 + 3.4. Certificate Request . . . . . . . . . . . . . . . . . . . . 6 + 3.5. Client Certificate . . . . . . . . . . . . . . . . . . . . 6 + 3.6. Other Handshake Messages . . . . . . . . . . . . . . . . . 6 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 2] + +Internet-Draft Using OpenPGP Keys January 2008 + + +1. Introduction + + The IETF has two sets of standards for public key certificates, one + set for use of X.509 certificates [PKIX] and one for OpenPGP + certificates [OpenPGP]. At the time of writing, TLS [TLS] standards + are defined to use only X.509 certificates. This document specifies + a way to negotiate use of OpenPGP certificates for a TLS session, and + specifies how to transport OpenPGP certificates via TLS. The + proposed extensions are backward compatible with the current TLS + specification, so that existing client and server implementations + that make use of X.509 certificates are not affected. + +2. Terminology + + The term "OpenPGP key" is used in this document as in the OpenPGP + specification [OpenPGP]. We use the term "OpenPGP certificate" to + refer to OpenPGP keys that are enabled for authentication. + + This document uses the same notation and terminology used in the TLS + Protocol specification [TLS]. + + 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]. + +3. Changes to the Handshake Message Contents + + This section describes the changes to the TLS handshake message + contents when OpenPGP certificates are to be used for authentication. + +3.1. Client Hello + + In order to indicate the support of multiple certificate types, + clients MUST include an extension of type "cert_type" (see Section 5) + to the extended client hello message. The hello extension mechanism + is described in [TLSEXT]. + + This extension carries a list of supported certificate types the + client can use, sorted by client preference. This extension MUST be + omitted if the client only supports X.509 certificates. The + "extension_data" field of this extension contains a + CertificateTypeExtension structure. + + + + + + + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 3] + +Internet-Draft Using OpenPGP Keys January 2008 + + + enum { client, server } ClientOrServerExtension; + + enum { X.509(0), OpenPGP(1), (255) } CertificateType; + + struct { + select(ClientOrServerExtension) { + case client: + CertificateType certificate_types<1..2^8-1>; + case server: + CertificateType certificate_type; + } + } CertificateTypeExtension; + + No new cipher suites are required to use OpenPGP certificates. All + existing cipher suites that support a compatible, with the key, key + exchange method can be used in combination with OpenPGP certificates. + +3.2. Server Hello + + If the server receives a client hello that contains the "cert_type" + extension and chooses a cipher suite that requires a certificate, + then two outcomes are possible. The server MUST either select a + certificate type from the certificate_types field in the extended + client hello or terminate the connection with a fatal alert of type + "unsupported_certificate". + + The certificate type selected by the server is encoded in a + CertificateTypeExtension structure, which is included in the extended + server hello message using an extension of type "cert_type". Servers + that only support X.509 certificates MAY omit including the + "cert_type" extension in the extended server hello. + + It is perfectly legal for a server to ignore this message. In that + case the normal TLS handshake should be used. Other certificate + types than the default MUST NOT be used. + +3.3. Server Certificate + + The contents of the certificate message sent from server to client + and vice versa are determined by the negotiated certificate type and + the selected cipher suite's key exchange algorithm. + + If the OpenPGP certificate type is negotiated, then it is required to + present an OpenPGP certificate in the certificate message. The + certificate must contain a public key that matches the selected key + exchange algorithm, as shown below. + + + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 4] + +Internet-Draft Using OpenPGP Keys January 2008 + + + Key Exchange Algorithm OpenPGP Certificate Type + + RSA RSA public key that can be used for + encryption. + + DHE_DSS DSS public key that can be used for + authentication. + + DHE_RSA RSA public key that can be used for + authentication. + + An OpenPGP certificate appearing in the certificate message is sent + using the binary OpenPGP format. The certificate MUST contain all + the elements required by Section 11.1 of [OpenPGP]. + + The option is also available to send an OpenPGP fingerprint, instead + of sending the entire certificate. The process of fingerprint + generation is described in Section 12.2 of [OpenPGP]. The peer shall + respond with a "certificate_unobtainable" fatal alert if the + certificate with the given fingerprint cannot be found. The + "certificate_unobtainable" fatal alert is defined in Section 4 of + [TLSEXT]. + + + enum { + cert_fingerprint (0), cert (1), subkey_cert (2), (255) + } OpenPGPCertDescriptorType; + + opaque OpenPGPCertFingerprint<16..20>; + + opaque OpenPGPCert<0..2^24-1>; + + struct { + opaque OpenPGPKeyID<1..8>; + opaque OpenPGPCert<0..2^24-1>; + } OpenPGPSubKeyCert; + + struct { + OpenPGPCertDescriptorType descriptorType; + select (descriptorType) { + case cert_fingerprint: OpenPGPCertFingerprint; + case cert: OpenPGPCert; + case subkey_cert: OpenPGPSubKeyCert; + } + } Certificate; + + + + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 5] + +Internet-Draft Using OpenPGP Keys January 2008 + + +3.4. Certificate Request + + The semantics of this message remain the same as in the TLS + specification. However, if this message is sent, and the negotiated + certificate type is OpenPGP, the "certificate_authorities" list MUST + be empty. + +3.5. Client Certificate + + This message is only sent in response to the certificate request + message. The client certificate message is sent using the same + formatting as the server certificate message, and it is also required + to present a certificate that matches the negotiated certificate + type. If OpenPGP certificates have been selected and no certificate + is available from the client, then a certificate structure that + contains an empty OpenPGPCert vector MUST be sent. The server SHOULD + respond with a "handshake_failure" fatal alert if client + authentication is required. + +3.6. Other Handshake Messages + + All the other handshake messages are identical to the TLS + specification. + +4. Security Considerations + + All security considerations discussed in [TLS], [TLSEXT], and + [OpenPGP] apply to this document. Considerations about the use of + the web of trust or identity and certificate verification procedure + are outside the scope of this document. These are considered issues + to be handled by the application layer protocols. + + The protocol for certificate type negotiation is identical in + operation to ciphersuite negotiation of the [TLS] specification with + the addition of default values when the extension is omitted. Since + those omissions have a unique meaning and the same protection is + applied to the values as with ciphersuites, it is believed that the + security properties of this negotiation are the same as with + ciphersuite negotiation. + + When using OpenPGP fingerprints instead of the full certificates, the + discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs" + applies, especially when external servers are used to retrieve keys. + However, a major difference is that although the + "client_certificate_url" extension allows identifying certificates + without including the certificate hashes, this is not possible in the + protocol proposed here. In this protocol, the certificates, when not + sent, are always identified by their fingerprint, which serves as a + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 6] + +Internet-Draft Using OpenPGP Keys January 2008 + + + cryptographic hash of the certificate (see Section 12.2 of + [OpenPGP]). + + The information that is available to participating parties and + eavesdroppers (when confidentiality is not available through a + previous handshake) is the number and the types of certificates they + hold, plus the contents of certificates. + +5. IANA Considerations + + This document defines a new TLS extension, "cert_type", assigned a + value of 9 from the TLS ExtensionType registry defined in [TLSEXT]. + This value is used as the extension number for the extensions in both + the client hello message and the server hello message. The new + extension type is used for certificate type negotiation. + + The "cert_type" extension contains an 8-bit CertificateType field, + for which a new registry, named "TLS Certificate Types", is + established in this document, to be maintained by IANA. The registry + is segmented in the following way: + + 1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. + + 2. Values from 2 through 223 decimal inclusive are assigned via IETF + Consensus [RFC2434]. + + 3. Values from 224 decimal through 255 decimal inclusive are + reserved for Private Use [RFC2434]. + +6. Acknowledgements + + This document was based on earlier work made by Will Price and + Michael Elkins. + + The author wishes to thank Werner Koch, David Taylor, Timo Schulz, + Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie + Orman for their suggestions on improving this document. + +7. References + +7.1. Normative References + + [TLS] Dierks, T. and E. Rescorla, "The TLS Protocol Version + 1.1", RFC 4346, April 2006. + + [OpenPGP] Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R. + Thayer, "OpenPGP Message Format", RFC 4880, October 2007. + + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 7] + +Internet-Draft Using OpenPGP Keys January 2008 + + + [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, April 2006. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", RFC 2434, + October 1998. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + +7.2. Informative References + + [PKIX] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + +Author's Address + + Nikos Mavrogiannopoulos + Independent + Arkadias 8 + Halandri, Attiki 15234 + Greece + + EMail: nmav@gnutls.org + URI: http://www.gnutls.org/ + + + + + + + + + + + + + + + + + + + + + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 8] + +Internet-Draft Using OpenPGP Keys January 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Mavrogiannopoulos Expires July 4, 2008 [Page 9] + |