updated drafts

2 files changed, 1105 insertions, 266 deletions

diff --git a/doc/protocol/draft-ietf-tls-compression-00.txt b/doc/protocol/draft-ietf-tls-compression-00.txt
new file mode 100644
index 0000000000..cef5100b47
--- /dev/null
+++ b/doc/protocol/draft-ietf-tls-compression-00.txt
@@ -0,0 +1,671 @@
+
+
+Network Working Group                                      S. Hollenbeck
+Internet-Draft                                            VeriSign, Inc.
+Expires: March 6, 2003                                 September 5, 2002
+
+
+         Transport Layer Security Protocol Compression Methods
+                     draft-ietf-tls-compression-00.txt
+
+Status of this Memo
+
+   This document is an Internet-Draft and is in full conformance with
+   all provisions of Section 10 of RFC2026.
+
+   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 March 6, 2003.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The Transport Layer Security (TLS) protocol (RFC 2246) includes
+   features to negotiate selection of a lossless data compression method
+   as part of the TLS Handshake Protocol and to then apply the algorithm
+   associated with the selected method as part of the TLS Record
+   Protocol.  TLS defines one standard compression method,
+   CompressionMethod.null, which specifies that data exchanged via the
+   record protocol will not be compressed.  This document describes
+   additional compression methods associated with lossless data
+   compression algorithms for use with TLS.
+
+Conventions Used In This Document
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 1]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+   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 [1].
+
+Table of Contents
+
+   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2. Compression Methods  . . . . . . . . . . . . . . . . . . . . .   4
+   3. Intellectual Property Considerations . . . . . . . . . . . . .   5
+   4. Internationalization Considerations  . . . . . . . . . . . . .   6
+   5. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .   7
+   6. Security Considerations  . . . . . . . . . . . . . . . . . . .   8
+   7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .   9
+      Normative References . . . . . . . . . . . . . . . . . . . . .  10
+      Informative References . . . . . . . . . . . . . . . . . . . .  11
+      Author's Address . . . . . . . . . . . . . . . . . . . . . . .  11
+      Full Copyright Statement . . . . . . . . . . . . . . . . . . .  12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 2]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+1. Introduction
+
+   The Transport Layer Security (TLS) protocol (RFC 2246, [2]) includes
+   features to negotiate selection of a lossless data compression method
+   as part of the TLS Handshake Protocol and to then apply the algorithm
+   associated with the selected method as part of the TLS Record
+   Protocol.  TLS defines one standard compression method,
+   CompressionMethod.null, which specifies that data exchanged via the
+   record protocol will not be compressed.  While this single
+   compression method helps ensure that TLS implementations are
+   interoperable, the lack of additional standard compression methods
+   has limited the ability of implementers to develop interoperable
+   implementations that include data compression.
+
+   TLS is used extensively to secure client-server connections on the
+   World Wide Web.  While these connections can often be characterized
+   as short-lived and exchanging relatively small amounts of data, TLS
+   is also being used in environments where connections can be long-
+   lived and the amount of data exchanged can extend into thousands or
+   millions of octets.  XML [4], for example, is increasingly being used
+   as a data representation method on the Internet, and XML tends to be
+   verbose.  Compression within TLS is one way to help reduce the
+   bandwidth and latency requirements associated with exchanging large
+   amounts of data while preserving the security services provided by
+   TLS.
+
+   This document describes additional compression methods associated
+   with lossless data compression algorithms for use with TLS.
+   Standardization of the compressed data formats and compression
+   algorithms associated with the compression methods is beyond the
+   scope of this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 3]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+2. Compression Methods
+
+   TLS [2] includes the following compression method structure in
+   sections 6.1 and 7.4.1.2 and Appendix sections A.4.1 and A.6:
+
+   enum { null(0), (255) } CompressionMethod;
+
+   which allows for later specification of up to 256 different
+   compression methods.  This definition is updated to segregate the
+   range of allowable values into three zones:
+
+   1.  Values from 0 (zero) through 63 decimal (0x3F) inclusive are
+       reserved for future standardization efforts of the IETF TLS
+       working group.
+
+   2.  Values from 64 decimal (0x40) through 192 decimal (0xC0) are
+       reserved for assignment by the IANA for specifications developed
+       outside the TLS working group.  Assignments from this range of
+       values MUST be made by the IANA and MUST be associated with a
+       formal reference that describes the compression method.
+
+   3.  Values from 193 decimal (0xC1) through 255 decimal (0xFF) are
+       reserved for private use.
+
+   Additional information describing the role of the IANA in the
+   allocation of compression method identifiers is described in Section
+   5.
+
+   In addition, this definition is updated to include assignment of
+   three additional compression methods:
+
+   enum { null(0), ZLIB(1), LZS(2), RLE(3), (255) } CompressionMethod;
+
+   The ZLIB compression method is described in RFC 1950 [5].  The Lempel
+   Zif Stac (LZS) compression method is described in ANSI publication
+   X3-241 [6].  The Run Length Encoding (RLE) compression method is
+   described in part 5 of the Digital Imaging and Communications in
+   Medicine standard [7].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 4]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+3. Intellectual Property Considerations
+
+   Many compression algorithms are subject to patent or other
+   intellectual property rights claims.  Implementers are encouraged to
+   seek legal guidance to better understand the implications of
+   developing implementations of the compression methods described in
+   this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 5]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+4. Internationalization Considerations
+
+   The compression method identifiers specified in this document are
+   machine-readable numbers.  As such, issues of human
+   internationalization and localization are not introduced.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 6]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+5. IANA Considerations
+
+   This document does not have a direct impact on the IANA, but it does
+   define ranges of compression method values for future assignment.
+   Values from the range reserved for future standardization efforts of
+   the TLS working group MUST be assigned according to the "Standards
+   Action" policy described in RFC 2434 [3].  Values from the range
+   reserved for private use MUST be used according to the "Private Use"
+   policy described in RFC 2434.  Values from the general IANA pool MUST
+   be assigned according to the "IETF Consensus" policy described in RFC
+   2434.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 7]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+6. Security Considerations
+
+   This document does not introduce any topics that alter the threat
+   model addressed by TLS.  However, data compression prior to
+   encryption can potentially provide a security benefit in "flattening"
+   the distribution of unencrypted octets (or increasing the unicity
+   distance) by using fewer bits to represent common characters.  In
+   situations where the unencrypted octets represent human-readable
+   text, reducing the predictability of text patterns can make it
+   slightly more difficult to mount a successful attack on the encrypted
+   octets.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 8]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+7. Acknowledgements
+
+   The concepts described in this document were originally discussed on
+   the IETF TLS working group mailing list in December, 2000.  The
+   author acknowledges the contributions to that discussion provided by
+   Jeffrey Altman, Eric Rescorla, and Marc Van Heyningen.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                  [Page 9]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
+        P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
+        1999.
+
+   [3]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                 [Page 10]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+Informative References
+
+   [4]  Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
+        "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml,
+        October 2000, <http://www.w3.org/TR/REC-xml>.
+
+   [5]  Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
+        Specification version 3.3", RFC 1950, May 1996.
+
+   [6]  American National Standards Institute, "Data Compression Method,
+        Adaptive Coding with Sliding Window of Information Interchange",
+        ANSI X3.241, 1994.
+
+   [7]  National Electrical Manufacturers Association, "Digital Imaging
+        and Communications in Medicine (DICOM) Part 5: Data Structures
+        and Encoding", 2001, <http://medical.nema.org/dicom/2001/
+        01_05PU.PDF>.
+
+
+Author's Address
+
+   Scott Hollenbeck
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   US
+
+   EMail: shollenbeck@verisign.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                 [Page 11]
+
+Internet-Draft          TLS Compression Methods           September 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   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 is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hollenbeck               Expires March 6, 2003                 [Page 12]
diff --git a/doc/protocol/draft-ietf-tls-extensions-03.txt b/doc/protocol/draft-ietf-tls-extensions-05.txt
index e3b0ee2184..cfcde376cc 100644
--- a/doc/protocol/draft-ietf-tls-extensions-03.txt
+++ b/doc/protocol/draft-ietf-tls-extensions-05.txt
@@ -2,16 +2,16 @@
 
 
 
-TLS Working Group                           Simon Blake-Wilson, Certicom
+TLS Working Group                                Simon Blake-Wilson, BCI
 INTERNET-DRAFT                              Magnus Nystrom, RSA Security
-February 22, 2002                  David Hopwood, Independent Consultant
-Expires August 22, 2002                   Jan Mikkelsen, Transactionware
+July 30, 2002                      David Hopwood, Independent Consultant
+Expires January 30, 2003                  Jan Mikkelsen, Transactionware
 Intended Category: Standards track                  Tim Wright, Vodafone
 
 
-                             TLS Extensions
+               Transport Layer Security (TLS) Extensions
 
-                   <draft-ietf-tls-extensions-03.txt>
+                   <draft-ietf-tls-extensions-05.txt>
 
                           Status of this Memo
 
@@ -53,9 +53,9 @@ Intended Category: Standards track                  Tim Wright, Vodafone
 
 
 
-Blake-Wilson et al.       Expires: August 2002                  [Page 1]
+Blake-Wilson et al.       Expires: January 2003                 [Page 1]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
    Please send comments on this document to the TLS mailing list.
@@ -72,23 +72,25 @@ INTERNET-DRAFT               TLS Extensions                February 2002
     3.1. Server Name Indication .................................. 8
     3.2. Maximum Fragment Length Negotiation ..................... 9
     3.3. Client Certificate URLs ................................ 11
-    3.4. Trusted CA Indication .................................. 12
+    3.4. Trusted CA Indication .................................. 13
     3.5. Truncated HMAC ......................................... 14
     3.6. Certificate Status Request.............................. 15
-    4. Error alerts ............................................. 16
-    5. Procedure for Defining New Extensions..................... 18
-    6. Security Considerations .................................. 19
-    6.1. Security of server_name ................................ 19
-    6.2. Security of max_fragment_length ........................ 19
+    4. Error alerts ............................................. 17
+    5. Procedure for Defining New Extensions..................... 19
+    6. Security Considerations .................................. 20
+    6.1. Security of server_name ................................ 20
+    6.2. Security of max_fragment_length ........................ 20
     6.3. Security of client_certificate_url ..................... 20
-    6.4. Security of trusted_ca_keys ............................ 20
-    6.5. Security of truncated_hmac ............................. 21
-    6.6. Security of status_request ............................. 21
-    7. Internationalization Considerations .......................21
-    8. Intellectual Property Rights ............................. 22
-    9. Acknowledgments .......................................... 22
-   10. References ............................................... 22
-   11. Authors' Addresses ....................................... 23
+    6.4. Security of trusted_ca_keys ............................ 22
+    6.5. Security of truncated_hmac ............................. 22
+    6.6. Security of status_request ............................. 22
+    7. Internationalization Considerations ...................... 22
+    8. IANA Considerations ...................................... 23
+    9. Intellectual Property Rights ............................. 24
+   10. Acknowledgments .......................................... 24
+   11. Normative References ..................................... 24
+   12. Informative References ................................... 25
+   13. Authors' Addresses ....................................... 26
 
 1. Introduction
 
@@ -104,16 +106,16 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    new environments like wireless networks.
 
    Wireless environments often suffer from a number of constraints not
-   commonly present in wired environments - these constraints may
-   include bandwidth limitations, computational power limitations,
 
 
 
-Blake-Wilson et al.       Expires: August 2002                  [Page 2]
+Blake-Wilson et al.       Expires: January 2003                 [Page 2]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
+   commonly present in wired environments - these constraints may
+   include bandwidth limitations, computational power limitations,
    memory limitations, and battery life limitations.
 
    The extensions described here focus on extending the functionality
@@ -160,21 +162,22 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    The extensions described in this document may be used by TLS 1.0
    clients and TLS 1.0 servers. The extensions are designed to be
    backwards compatible - meaning that TLS 1.0 clients that support the
-   extensions can talk to TLS 1.0 servers that do not support the
-   extensions, and vice versa.
 
 
 
-Blake-Wilson et al.       Expires: August 2002                  [Page 3]
+Blake-Wilson et al.       Expires: January 2003                 [Page 3]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
+   extensions can talk to TLS 1.0 servers that do not support the
+   extensions, and vice versa.
+
    Backwards compatibility is primarily achieved via two considerations:
 
    - Clients typically request the use of extensions via the extended
      client hello message described in Section 2.1. TLS 1.0 [TLS]
-     requires servers to "accept" extended client hello messages, even
+     requires servers to accept extended client hello messages, even
      if the server does not "understand" the extension.
 
    - For the specific extensions described here, no mandatory server
@@ -190,7 +193,8 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    server hello handshake messages. Section 3 describes specific
    extensions to TLS 1.0. Section 4 describes new error alerts for use
    with the TLS extensions. The final sections of the document address
-   IPR, security considerations, acknowledgements, and references.
+   IPR, security considerations, registration of the
+   application/pkix-pkipath MIME type, acknowledgements, and references.
 
 2. General Extension Mechanisms
 
@@ -213,19 +217,20 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    the extended client hello message format in place of the client hello
    message format. The extended client hello message format is:
 
-       struct {
-           ProtocolVersion client_version;
-           Random random;
-           SessionID session_id;
-           CipherSuite cipher_suites<2..2^16-1>;
 
 
 
-Blake-Wilson et al.       Expires: August 2002                  [Page 4]
+
+Blake-Wilson et al.       Expires: January 2003                 [Page 4]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
+       struct {
+           ProtocolVersion client_version;
+           Random random;
+           SessionID session_id;
+           CipherSuite cipher_suites<2..2^16-1>;
            CompressionMethod compression_methods<1..2^8-1>;
            Extension client_hello_extension_list<0..2^16-1>;
        } ClientHello;
@@ -233,9 +238,9 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    Here the new "client_hello_extension_list" field contains a list of
    extensions. The actual "Extension" format is defined in Section 2.3.
 
-   In the event that clients request additional functionality using the
-   extended client hello, and this functionality is not supplied by the
-   server, clients MAY abort the handshake.
+   In the event that a client requests additional functionality using
+   the extended client hello, and this functionality is not supplied by
+   the server, the client MAY abort the handshake.
 
    Note that [TLS], Section 7.4.1.2, allows additional information to be
    added to the client hello message. Thus the use of the extended
@@ -267,21 +272,19 @@ INTERNET-DRAFT               TLS Extensions                February 2002
 
    Here the new "server_hello_extension_list" field contains a list of
    extensions. The actual "Extension" format is defined in Section 2.3.
-
    Note that the extended server hello message is only sent in response
    to an extended client hello message. This prevents the possibility
-   that the extended server hello message could "break" existing TLS 1.0
-   clients.
 
 
 
-
-
-Blake-Wilson et al.       Expires: August 2002                  [Page 5]
+Blake-Wilson et al.       Expires: January 2003                 [Page 5]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
+   that the extended server hello message could "break" existing TLS 1.0
+   clients.
+
  2.3. Hello Extensions
 
    The extension format for extended client hellos and extended server
@@ -327,17 +330,17 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    relevant only when a session is initiated. However, a client that
    requests resumption of a session does not in general know whether the
    server will accept this request, and therefore it SHOULD send an
-   extended client hello if it would normally do so for a new session.
-   If the resumption request is denied, then a new set of extensions
-   will be negotiated as normal. If, on the other hand, the older
 
 
 
-Blake-Wilson et al.       Expires: August 2002                  [Page 6]
+Blake-Wilson et al.       Expires: January 2003                 [Page 6]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
+   extended client hello if it would normally do so for a new session.
+   If the resumption request is denied, then a new set of extensions
+   will be negotiated as normal. If, on the other hand, the older
    session is resumed, then the server MUST ignore extensions appearing
    in the client hello, and send a server hello containing no
    extensions; in this case the extension functionality negotiated
@@ -384,16 +387,15 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    This section describes the specific TLS extensions specified in this
    document.
 
-   Note that any messages associated with these extensions that are sent
-   during the TLS handshake MUST be included in the hash calculations
 
 
-
-Blake-Wilson et al.       Expires: August 2002                  [Page 7]
+Blake-Wilson et al.       Expires: January 2003                 [Page 7]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
+   Note that any messages associated with these extensions that are sent
+   during the TLS handshake MUST be included in the hash calculations
    involved in "Finished" messages.
 
    Section 3.1 describes the extension of TLS to allow a client to
@@ -423,7 +425,7 @@ INTERNET-DRAFT               TLS Extensions                February 2002
            NameType name_type;
            select (name_type) {
                case host_name: HostName;
-           }
+           } name;
        } ServerName;
 
        enum {
@@ -440,23 +442,23 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    this does not imply any dependency of TLS on DNS, and other name
    types may be added in the future (by an RFC that Updates this
    document).  TLS MAY treat provided server names as opaque data and
-   pass the names and types to the application.
 
 
 
-
-Blake-Wilson et al.       Expires: August 2002                  [Page 8]
+Blake-Wilson et al.       Expires: January 2003                 [Page 8]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
+   pass the names and types to the application.
+
    "HostName" contains the fully qualified DNS hostname of the server,
    as understood by the client. The hostname is represented as a byte
    string using UTF-8 encoding [UTF8], without a trailing dot.  (Note
    that the use of UTF-8 here for encoding internationalized hostnames
    is independent of the choice of encoding for these names in the DNS
-   protocol. The latter has yet to be decided by the IETF
-   Internationalized Domain Name Working Group [IDNWG].)
+   protocol. At the time of writing, the latter had yet to be finalized
+   by the IETF Internationalized Domain Name Working Group [IDNWG].)
 
    If the server needs to match the HostName against names that contain
    non-ASCII characters (that is, if it has one or more
@@ -496,16 +498,17 @@ INTERNET-DRAFT               TLS Extensions                February 2002
 
    [TLS] specifies a fixed maximum plaintext fragment length of 2^14
    bytes.  It may be desirable for constrained clients to negotiate a
-   smaller maximum fragment length due to memory limitations or
-   bandwidth limitations.
 
 
 
-Blake-Wilson et al.       Expires: August 2002                  [Page 9]
+Blake-Wilson et al.       Expires: January 2003                 [Page 9]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
+   smaller maximum fragment length due to memory limitations or
+   bandwidth limitations.
+
    In order to negotiate smaller maximum fragment lengths, clients MAY
    include an extension of type "max_fragment_length" in the (extended)
    client hello.  The "extension_data" field of this extension SHALL
@@ -548,19 +551,21 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    TLSPlaintext.length; see [TLS] section 6.2.1).  Note that the output
    of the record layer may be larger. For example, if the negotiated
    length is 2^9=512, then for currently defined cipher suites (those
-   defined in [TLS], [KERB], and planned AES ciphersuites), the record
-   layer output can be at most 793 bytes: 5 bytes of headers, 512 bytes
-   of application data, 256 bytes of padding, and 20 bytes of MAC. That
-   means that in this event a TLS record layer peer receiving a TLS
-   record layer message larger than 793 bytes may discard the message
-   and send a "record_overflow" alert, without decrypting the message.
+   defined in [TLS], [KERB], and planned AES cipher suites), and when
+   null compression is used, the record layer output can be at most 793
+   bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes
 
 
 
-Blake-Wilson et al.       Expires: August 2002                 [Page 10]
+Blake-Wilson et al.       Expires: January 2003                [Page 10]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
 
+   of padding, and 20 bytes of MAC. That means that in this event a TLS
+   record layer peer receiving a TLS record layer message larger than
+   793 bytes may discard the message and send a "record_overflow" alert,
+   without decrypting the message.
 
  3.3. Client Certificate URLs
 
@@ -589,61 +594,98 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    "client_certificate_url" extensions), clients MAY send a
    "CertificateURL" message in place of a "Certificate" message:
 
+       enum {
+           individual_certs(0), pkipath(1), (255)
+       } CertChainType;
+
+       enum {
+           false(0), true(1)
+       } Boolean;
+
        struct {
-           URLAndHash url_and_hash_list<1..2^16-1>;
+           CertChainType type;
+           URLAndOptionalHash url_and_hash_list<1..2^16-1>;
        } CertificateURL;
 
        struct {
-           opaque URL<1..2^16-1>;
-           CertHash certificate_hash;
-       } URLAndHash;
+           opaque url<1..2^16-1>;
+           Boolean hash_present;
 
-       opaque CertHash<0..20>;
 
-   Here "url_and_hash_list" contains a sequence of URLs and hashes.
 
-   When X.509 certificates are used, each URL refers either to a single,
-   DER-encoded X.509v3 certificate, or to a PKCS #7 certificate chain.
-   For ciphersuites using other certificate formats, the ciphersuite
-   specification must define the encoding format of certificates or
-   certificate chains, and any constraint on their ordering, if this
-   message is to be used.
+Blake-Wilson et al.       Expires: January 2003                [Page 11]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
-   The hash corresponding to each URL at the client's discretion is
 
+           select (hash_present) {
+               case false: struct {};
+               case true: SHA1Hash;
+           } hash;
+       } URLAndOptionalHash;
 
+       opaque SHA1Hash[20];
 
-Blake-Wilson et al.       Expires: August 2002                 [Page 11]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
+   Here "url_and_hash_list" contains a sequence of URLs and optional
+   hashes.
+
+   When X.509 certificates are used, there are two possibilities:
+
+   - if CertificateURL.type is "individual_certs", each URL refers
+     to a single DER-encoded X.509v3 certificate, with the URL for
+     the client's certificate first, or
+
+   - if CertificateURL.type is "pkipath", the list contains a single
+     URL referring to a DER-encoded certificate chain, using the type
+     PkiPath described in Section 8.
 
+   When any other certificate format is used, the specification that
+   describes use of that format in TLS should define the encoding format
+   of certificates or certificate chains, and any constraint on their
+   ordering.
 
-   either empty or it contains the SHA-1 hash of the certificate or
+   The hash corresponding to each URL at the client's discretion is
+   either not present or is the SHA-1 hash of the certificate or
    certificate chain (in the case of X.509 certificates, the DER-encoded
-   certificate or the DER-encoded CertificateSet, see [CMS]).
+   certificate or the DER-encoded PkiPath).
 
-   For X.509, URLs MUST occur in the list in the same order that the
-   corresponding certificates appear in the certificate chain.
+   Note that when a list of URLs for X.509 certificates is used, the
+   ordering of URLs is the same as that used in the TLS Certificate
+   message (see [TLS] Section 7.4.2), but opposite to the order in which
+   certificates are encoded in PkiPath. In either case, the self-signed
+   root certificate MAY be omitted from the chain, under the assumption
+   that the server must already possess it in order to validate it.
 
    Servers receiving "CertificateURL" SHALL attempt to retrieve the
    client's certificate chain from the URLs, and then process the
-   certificate chain as usual. Servers that support this extension MUST
-   support the http: URL scheme for certificate URLs, and MAY support
-   other schemes.
-
-   In general, the format of the certificates retrieved by the server
-   will depend on the protocol used by the server to retrieve them, as
-   recommended by the PKIX working group. In the case of HTTP, the
-   response MUST be a MIME formatted response. When a single X.509v3
-   certificate is returned, the Content-type is application/pkix-cert
-   [PKIOP]. When a chain of X.509v3 certificates is returned, the
-   Content-type is application/pkcs7-mime [SMIME].
-
-   Servers MUST check that the SHA-1 hash of any certificates retrieved
-   from a CertificateURL matches the given hash if it is present.  If
-   any retrieved certificate does not have the correct SHA-1 hash, the
-   server MUST abort the handshake with a "bad_certificate_hash_value"
-   alert.
+   certificate chain as usual. A cached copy of the content of any URL
+   in the chain MAY be used, provided that a SHA-1 hash is present for
+   that URL and it matches the hash of the cached copy.
+
+   Servers that support this extension MUST support the http: URL scheme
+   for certificate URLs, and MAY support other schemes.
+
+   If the protocol used to retrieve certificates or certificate chains
+
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 12]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
+   returns a MIME formatted response (as HTTP does), then the following
+   MIME Content-Types SHALL be used: when a single X.509v3 certificate
+   is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
+   when a chain of X.509v3 certificates is returned, the Content-Type is
+   "application/pkix-pkipath" (see Section 8).
+
+   If a SHA-1 hash is present for an URL, then the server MUST check
+   that the SHA-1 hash of the contents of the object retrieved from that
+   URL (after decoding any MIME Content-Transfer-Encoding) matches the
+   given hash. If any retrieved object does not have the correct SHA-1
+   hash, the server MUST abort the handshake with a
+   "bad_certificate_hash_value" alert.
 
    Note that clients may choose to send either "Certificate" or
    "CertificateURL" after successfully negotiating the option to send
@@ -666,14 +708,6 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    client hello. The "extension_data" field of this extension SHALL
    contain "TrustedAuthorities" where:
 
-
-
-
-Blake-Wilson et al.       Expires: August 2002                 [Page 12]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
-
-
        struct {
            TrustedAuthority trusted_authorities_list<0..2^16-1>;
        } TrustedAuthorities;
@@ -682,36 +716,44 @@ INTERNET-DRAFT               TLS Extensions                February 2002
            IdentifierType identifier_type;
            select (identifier_type) {
                case pre_agreed: struct {};
-               case key_hash_sha: KeyHash;
+               case key_sha1_hash: SHA1Hash;
                case x509_name: DistinguishedName;
-               case cert_hash: CertHash;
-           } Identifier;
+               case cert_sha1_hash: SHA1Hash;
+           } identifier;
        } TrustedAuthority;
 
-       enum { pre_agreed(0), key_hash_sha(1), x509_name(2), cert_hash(3),
-           (255)}
-           IdentifierType;
 
-       opaque DistinguishedName<1..2^16-1>;
 
-       opaque KeyHash[20];
+
+Blake-Wilson et al.       Expires: January 2003                [Page 13]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
+       enum {
+           pre_agreed(0), key_sha1_hash(1), x509_name(2),
+           cert_sha1_hash(3), (255)
+       } IdentifierType;
+
+       opaque DistinguishedName<1..2^16-1>;
 
    Here "TrustedAuthorities" provides a list of CA root key identifiers
    that the client possesses. Each CA root key is identified via either:
 
    - "pre_agreed" - no CA root key identity supplied.
 
-   - "key_hash_sha" - contains the SHA-1 hash of the CA root key. For
+   - "key_sha1_hash" - contains the SHA-1 hash of the CA root key. For
       DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
-      value. For RSA keys, this is the hash of the byte string
-      representation of the modulus (without any initial 0-valued
-      bytes). (This copies the key hash formats deployed in other
+      value. For RSA keys, the hash is of the big-endian byte string
+      representation of the modulus without any initial 0-valued
+      bytes. (This copies the key hash formats deployed in other
       environments.)
 
-   - "cert_hash" - contains the SHA-1 hash of a certificate containing
-      the CA root key.
+   - "x509_name" - contains the DER-encoded X.509 DistinguishedName
+      of the CA.
 
-   - "x509_name" - contains the X.509 Distinguished Name of the CA.
+   - "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded
+      Certificate containing the CA root key.
 
    Note that clients may include none, some, or all of the CA root keys
    they possess in this extension.
@@ -722,14 +764,6 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    is the case following the use of Distinguished Names to identify
    certificate issuers in TLS.
 
-
-
-
-Blake-Wilson et al.       Expires: August 2002                 [Page 13]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
-
-
    The option to include no CA root keys is included to allow the client
    to indicate possession of some pre-defined set of CA root keys.
 
@@ -742,8 +776,16 @@ INTERNET-DRAFT               TLS Extensions                February 2002
 
  3.5. Truncated HMAC
 
-   Currently defined TLS ciphersuites use the MAC construction HMAC with
-   either MD5 or SHA-1 [HMAC] to authenticate record layer
+   Currently defined TLS cipher suites use the MAC construction HMAC
+   with either MD5 or SHA-1 [HMAC] to authenticate record layer
+
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 14]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
    communications. In TLS the entire output of the hash function is used
    as the MAC tag. However it may be desirable in constrained
    environments to save bandwidth by truncating the output of the hash
@@ -755,17 +797,18 @@ INTERNET-DRAFT               TLS Extensions                February 2002
 
    Servers that receive an extended hello containing a "truncated_hmac"
    extension, MAY agree to use a truncated HMAC by including an
-   extension of type "truncated_hmac" in the extended server hello.
-
-   Note that if new ciphersuites are added that do not use HMAC, and the
-   session negotiates one of these ciphersuites, this extension will
-   have no effect. It is strongly recommended that any new cipher suites
-   using other MACs consider the MAC size as an integral part of the
-   cipher suite definition, taking into account both security and
+   extension of type "truncated_hmac", with empty "extension_data", in
+   the extended server hello.
+
+   Note that if new cipher suites are added that do not use HMAC, and
+   the session negotiates one of these cipher suites, this extension
+   will have no effect. It is strongly recommended that any new cipher
+   suites using other MACs consider the MAC size as an integral part of
+   the cipher suite definition, taking into account both security and
    bandwidth considerations.
 
    If HMAC truncation has been successfully negotiated during a TLS
-   handshake, and the negotiated ciphersuite uses HMAC, both the client
+   handshake, and the negotiated cipher suite uses HMAC, both the client
    and the server pass this fact to the TLS record layer along with the
    other negotiated security parameters. Subsequently during the
    session, clients and servers MUST use truncated HMACs, calculated as
@@ -777,15 +820,6 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    The negotiated HMAC truncation size applies for the duration of the
    session including session resumptions.
 
-
-
-
-
-Blake-Wilson et al.       Expires: August 2002                 [Page 14]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
-
-
  3.6. Certificate Status Request
 
    Constrained clients may wish to use a certificate-status protocol
@@ -800,14 +834,22 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    field of this extension SHALL contain "CertificateStatusRequest"
    where:
 
+
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 15]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
        struct {
            CertificateStatusType status_type;
            select (status_type) {
                case ocsp: OCSPStatusRequest;
-           }
+           } request;
        } CertificateStatusRequest;
 
-       enum { ocsp(1), 255) } CertificateStatusType;
+       enum { ocsp(1), (255) } CertificateStatusType;
 
        struct {
            ResponderID responder_id_list<0..2^16-1>;
@@ -824,7 +866,16 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    DER encoding of OCSP request extensions.
 
    Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
-   defined in [OCSP].
+   defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero-
+   length "request_extensions" value means that there are no extensions
+   (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
+   the "Extensions" type).
+
+   In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
+   unclear about its encoding; for clarification, the nonce MUST be a
+   DER-encoded OCTET STRING, which is encapsulated as another OCTET
+   STRING (note that implementations based on an existing OCSP client
+   will need to be checked for conformance to this requirement).
 
    Servers that receive a client hello containing the "status_request"
    extension, MAY return a suitable certificate status response to the
@@ -834,26 +885,26 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    request.
 
    Servers return a certificate response along with their certificate by
+   sending a "CertificateStatus" message immediately after the
+   "Certificate" message (and before any "ServerKeyExchange" or
+   "CertificateRequest" messages). If a server returns a
+   "CertificateStatus" message, then the server MUST have included an
+   extension of type "status_request" with empty "extension_data" in the
 
 
 
-Blake-Wilson et al.       Expires: August 2002                 [Page 15]
+Blake-Wilson et al.       Expires: January 2003                [Page 16]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
-   sending a "CertificateStatus" message immediately after the
-   "Certificate" message (and before any "ServerKeyExchange" or
-   "CertificateRequest" messages). If a server returns a
-   "CertificateStatus" message, then the server MUST have included an
-   extension of type "status_request" with empty "extension_data" in the
    extended server hello.
 
        struct {
            CertificateStatusType status_type;
            select (status_type) {
-               case ocsp: OCSPResponse ocsp_response;
-           }
+               case ocsp: OCSPResponse;
+           } response;
        } CertificateStatus;
 
        opaque OCSPResponse<1..2^24-1>;
@@ -890,20 +941,19 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    - "unsupported_extension" - this alert is sent by clients that
      receive an extended server hello containing an extension that
      they did not put in the corresponding client hello (see Section
-
-
-
-Blake-Wilson et al.       Expires: August 2002                 [Page 16]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
-
-
      2.3). This message is always fatal.
 
    - "unrecognized_name" - this alert is sent by servers that
      receive a server_name extension request, but do not recognize the
      server name. This message MAY be fatal.
 
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 17]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
    - "certificate_unobtainable" - this alert is sent by servers who are
      unable to retrieve a certificate chain from the URL supplied by
      the client (see Section 3.3). This message MAY be fatal - for
@@ -946,20 +996,20 @@ INTERNET-DRAFT               TLS Extensions                February 2002
            internal_error(80),
            user_canceled(90),
            no_renegotiation(100),
-
-
-
-Blake-Wilson et al.       Expires: August 2002                 [Page 17]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
-
-
            unsupported_extension(110),           /* new */
            certificate_unobtainable(111),        /* new */
            unrecognized_name(112),               /* new */
            bad_certificate_status_response(113), /* new */
            bad_certificate_hash_value(114),      /* new */
            (255)
+
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 18]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
        } AlertDescription;
 
 5. Procedure for Defining New Extensions
@@ -1003,18 +1053,19 @@ INTERNET-DRAFT               TLS Extensions                February 2002
       until the handshake has been authenticated, active attackers
       can modify messages and insert, remove, or replace extensions.
 
+    - It would be technically possible to use extensions to change
+      major aspects of the design of TLS; for example the design of
+      cipher suite negotiation. This is not recommended; it
+      would be more appropriate to define a new version of TLS -
+      particularly since the TLS handshake algorithms have specific
+
 
 
-Blake-Wilson et al.       Expires: August 2002                 [Page 18]
+Blake-Wilson et al.       Expires: January 2003                [Page 19]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
 
-    - It would be technically possible to use extensions to change
-      major aspects of the design of TLS; for example the design of
-      ciphersuite negotiation. This is not recommended; it
-      would be more appropriate to define a new version of TLS -
-      particularly since the TLS handshake algorithms have specific
       protection against version rollback attacks based on the
       version number, and the possibility of version rollback
       should be a significant consideration in any major design
@@ -1051,33 +1102,32 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    requires implementations to be able to handle fragmented handshake
    messages.
 
-   Note that as described in section 3.2, once a non-null ciphersuite
+   Note that as described in section 3.2, once a non-null cipher suite
    has been activated, the effective maximum fragment length depends on
-   the ciphersuite, as well as on the negotiated max_fragment_length.
-   This must be taken into account when sizing buffers, and checking for
-   buffer overflow.
-
+   the cipher suite and compression method, as well as on the negotiated
+   max_fragment_length. This must be taken into account when sizing
+   buffers, and checking for buffer overflow.
 
+ 6.3. Security of client_certificate_url
 
+   The major issue with this extension is whether or not clients should
+   include certificate hashes when they send certificate URLs.
 
+   When client authentication is used *without* the
 
-Blake-Wilson et al.       Expires: August 2002                 [Page 19]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
 
 
- 6.3. Security of client_certificate_url
+Blake-Wilson et al.       Expires: January 2003                [Page 20]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
-   The major issue with this extension is whether or not clients should
-   include certificate hashes when they send certificate URLs.
 
-   When client authentication is used *without* the
    client_certificate_url extension, the client certificate chain is
    covered by the Finished message hashes. The purpose of including
-   certificate hashes and checking them against the retrieved
-   certificate chain, is to ensure that the same property holds when
-   this extension is used - i.e. that all of the information in the
-   certificate chain retrieved by the server is as the client intended.
+   hashes and checking them against the retrieved certificate chain, is
+   to ensure that the same property holds when this extension is used -
+   i.e. that all of the information in the certificate chain retrieved
+   by the server is as the client intended.
 
    On the other hand, omitting certificate hashes enables functionality
    that is desirable in some circumstances - for example clients can be
@@ -1087,9 +1137,15 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    attacker obtains a valid certificate on the client's key that is
    different from the certificate the client intended to provide.
 
-   Note that although TLS uses both MD5 and SHA-1 hashes in several
-   other places, this was not believed to be necessary here. The
-   property required of SHA-1 is second pre-image resistance.
+   Also note that HTTP caching proxies are common on the Internet, and
+   some proxies do not check for the latest version of an object
+   correctly.  If a request using HTTP (or another caching protocol)
+   goes through a misconfigured or otherwise broken proxy, the proxy may
+   return an out-of-date response.
+
+   Although TLS uses both MD5 and SHA-1 hashes in several other places,
+   this was not believed to be necessary here. The property required of
+   SHA-1 is second pre-image resistance.
 
    Support for client_certificate_url involves the server acting as a
    client in another protocol (usually HTTP, but other URL schemes are
@@ -1101,12 +1157,27 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    service attacks: an attacker can make many connections, each of which
    results in the server making an HTTP request.
 
+   Note that the server may be behind a firewall or otherwise able to
+   access hosts that would not be directly accessible from the public
+   Internet; this could exacerbate the potential security and denial of
+   service problems described above, as well as allowing the existence
+   of internal hosts to be confirmed when they would otherwise be
+   hidden.
+
    It is RECOMMENDED that the client_certificate_url extension should
    have to be specifically enabled by a server administrator, rather
    than being enabled by default.
 
    As discussed in [URI], URLs that specify ports other than the default
    may cause problems, as may very long URLs (which are more likely to
+
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 21]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
    be useful in exploiting buffer overflow bugs).
 
  6.4. Security of trusted_ca_keys
@@ -1115,13 +1186,6 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    regarded as confidential information. As a result, the CA root key
    indication extension should be used with care.
 
-
-
-Blake-Wilson et al.       Expires: August 2002                 [Page 20]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
-
-
    The use of the SHA-1 certificate hash alternative ensures that each
    certificate is specified unambiguously. As for the previous
    extension, it was not believed necessary to use both MD5 and SHA-1
@@ -1152,8 +1216,8 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    If a client requests an OCSP response, it must take into account that
    an attacker's server using a compromised key could (and probably
    would) pretend not to support the extension. A client that requires
-   OCSP validation of certificates SHOULD be prepared to contact the
-   OCSP server directly in this case.
+   OCSP validation of certificates SHOULD either contact the OCSP server
+   directly in this case, or abort the handshake.
 
    Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
    improve security against attacks that attempt to replay OCSP
@@ -1162,23 +1226,102 @@ INTERNET-DRAFT               TLS Extensions                February 2002
 7. Internationalization Considerations
 
    None of the extensions defined here directly use strings subject to
+
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 22]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
    localization. DNS hostnames are encoded using UTF-8. If future
    extensions use text strings, then internationalization should be
    considered in their design.
 
+8. IANA Considerations
+
+   The MIME type "application/pkix-pkipath" is to be registered with the
+   following template:
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type application/pkix-pkipath
+
+   MIME media type name: application
 
+   MIME subtype name: pkix-pkipath
 
+   Required parameters: none
 
+   Optional parameters: version (default value is "1")
 
+   Encoding considerations:
+      This MIME type is a DER encoding of the ASN.1 type PkiPath,
+      defined as follows:
 
+         PkiPath ::= SEQUENCE OF Certificate
 
+         PkiPath is used to represent a certification path. Within the
+         sequence, the order of certificates is such that the subject of
+         the first certificate is the issuer of the second certificate,
+         etc.
 
-Blake-Wilson et al.       Expires: August 2002                 [Page 21]
+      This is identical to the definition that will be published in
+      [X509-4th-TC1]; note that it is different from that in [X509-4th].
+
+      All Certificates MUST conform to [PKIX]. (This should be interpreted
+      as a requirement to encode only PKIX-conformant certificates using
+      this type. It does not necessarily require that all certificates
+      that are not strictly PKIX-conformant must be rejected by relying
+      parties, although the security consequences of accepting any such
+      certificates should be considered carefully.)
+
+      DER (as opposed to BER) encoding MUST be used. If this type is
+      sent over a 7-bit transport, base64 encoding SHOULD be used.
+
+   Security considerations:
+      The security considerations of [X509-4th] and [PKIX] (or any
+      updates to them) apply, as well as those of any protocol that uses
+      this type (e.g. TLS).
+
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 23]
 
-INTERNET-DRAFT               TLS Extensions                February 2002
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
 
+      Note that this type only specifies a certificate chain that
+      can be assessed for validity according to the relying party's
+      existing configuration of trusted CAs; it is not intended to be
+      used to specify any change to that configuration.
 
-8. Intellectual Property Rights
+   Interoperability considerations:
+      No specific interoperability problems are known with this type,
+      but for recommendations relating to X.509 certificates in general,
+      see [PKIX].
+
+   Published specification: this memo, and [PKIX].
+
+   Applications which use this media type: TLS. It may also be used by
+      other protocols, or for general interchange of PKIX certificate
+      chains.
+
+   Additional information:
+      Magic number(s): DER-encoded ASN.1 can be easily recognised.
+         Further parsing is required to distinguish from other ASN.1
+         types.
+      File extension(s): .pkipath
+      Macintosh File Type Code(s): not specified
+
+   Person & email address to contact for further information:
+      Magnus Nystrom <magnus@rsasecurity.com>
+
+   Intended usage: COMMON
+
+   Author/Change controller:
+      Magnus Nystrom <magnus@rsasecurity.com>
+
+9. Intellectual Property Rights
 
    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
@@ -1186,68 +1329,84 @@ INTERNET-DRAFT               TLS Extensions                February 2002
    this document. Please address the information to the IETF Executive
    Director.
 
-9. Acknowledgments
+10. Acknowledgments
 
    The authors wish to thank the TLS Working Group and the WAP Security
    Group. This document is based on discussion within these groups.
 
-10. References
+11. Normative References
 
-   [CMS] R. Housley, "Cryptographic Message Syntax," IETF RFC 2630, June
-   1999.
+   [HMAC] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-hashing
+   for message authentication," IETF RFC 2104, February 1997.
 
-   [HMAC] Krawczyk, H., Bellare, M., and Canetti, R. - HMAC: Keyed-
-   hashing for message authentication. IETF RFC 2104, February 1997.
 
-   [HTTP] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T.
-   Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," IETF RFC
-   2616, June 1999.
 
-   [IDNWG] IETF Internationalized Domain Name Working Group,
-   http://www.i-d-n.net/
+Blake-Wilson et al.       Expires: January 2003                [Page 24]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
 
-   [KERB] A. Medvinsky, M. Hur, "Addition of Kerberos Cipher Suites to
-   Transport Layer Security (TLS)," IETF RFC 2712, October 1999.
+
+   [HTTP] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T.
+   Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," IETF RFC
+   2616, June 1999.
 
    [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
    Requirement Levels," IETF RFC 2119, March 1997.
 
-   [MAILING LIST] Mikkelsen, J. Eberhard, R., and J. Kistler, "General
-   ClientHello extension mechanism and virtual hosting," Ietf-tls
-   mailing list posting, August 14, 2000.
-
-   [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
-   Adams, "Internet X.509 Public Key Infrastructure: Online Certificate
-   Status Protocol - OCSP," IETF RFC 2560, June 1999.
+   [OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams,
+   "Internet X.509 Public Key Infrastructure: Online Certificate Status
+   Protocol - OCSP," IETF RFC 2560, June 1999.
 
-   [PKIOP] Housley, R., and P. Hoffman, "Internet X.509 Public Key
+   [PKIOP] R. Housley and P. Hoffman, "Internet X.509 Public Key
    Infrastructure - Operation Protocols: FTP and HTTP," IETF RFC 2585,
    May 1999.
 
-   [SMIME] B. Ramsdell, "S/MIME Version 3 Message Specification," IETF
-   RFC 2633, June 1999.
+   [PKIX] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet Public
+   Key Infrastructure - Certificate and Certificate Revocation List
+   (CRL) Profile", IETF RFC 3280, April 2002.
 
+   [TLS] T. Dierks and C. Allen, "The TLS Protocol - Version 1.0," IETF
+   RFC 2246, January 1999.
 
+   [URI] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource
+   Identifiers (URI): Generic Syntax," IETF RFC 2396, August 1998.
 
-Blake-Wilson et al.       Expires: August 2002                 [Page 22]
-
-INTERNET-DRAFT               TLS Extensions                February 2002
+   [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 10646,"
+   IETF RFC 2279, January 1998.
 
+   [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001,
+   "Information Systems - Open Systems Interconnection - The Directory:
+   Public key and attribute certificate frameworks."
 
-   [TLS] Dierks, T., and C. Allen, "The TLS Protocol - Version 1.0,"
-   IETF RFC 2246, January 1999.
+   [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
+   ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC
+   9594:8:2001.
 
-   [URI] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
-   Identifiers (URI): Generic Syntax," IETF RFC 2396, August 1998.
+12. Informative References
+
+   [IDNWG] IETF Internationalized Domain Name Working Group,
+   http://www.i-d-n.net/
+
+   [KERB] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher Suites
+   to Transport Layer Security (TLS)," IETF RFC 2712, October 1999.
+
+   [MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
+   ClientHello extension mechanism and virtual hosting," ietf-tls
+   mailing list posting, August 14, 2000.
 
-   [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 10646,"
-   IETF RFC 2279, January 1998.
 
-11. Authors' Addresses
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 25]
+
+INTERNET-DRAFT               TLS Extensions                    July 2002
+
+
+13. Authors' Addresses
 
    Simon Blake-Wilson
-   Certicom Corp.
-   sblake-wilson@certicom.com
+   BCI
+   sblakewilson@bcisse.com
 
    Magnus Nystrom
    RSA Security
@@ -1285,4 +1444,13 @@ INTERNET-DRAFT               TLS Extensions                February 2002
 
 
 
-Blake-Wilson et al.       Expires: August 2002                 [Page 23]
+
+
+
+
+
+
+
+
+
+Blake-Wilson et al.       Expires: January 2003                [Page 26]