< draft-ietf-tls-rfc3546bis-01.txt   draft-ietf-tls-rfc3546bis-02.txt >
TLS Working Group S. Blake-Wilson TLS Working Group S. Blake-Wilson
Internet-Draft BCI Internet-Draft BCI
Obsoletes: 3546 (if approved) M. Nystrom Obsoletes: 3546 (if approved) M. Nystrom
Updates: 2246 RSA Security Updates: 2246 & [TBD for TLS1.1 RFC] RSA Security
Category: Standards Track D. Hopwood Category: Standards Track D. Hopwood
Expires: November 2005 Independent Consultant Expires: March 2006 Independent Consultant
J. Mikkelsen J. Mikkelsen
Transactionware Transactionware
T. Wright T. Wright
Vodafone Vodafone
May 2005 September 2005
Transport Layer Security (TLS) Extensions Transport Layer Security (TLS) Extensions
<draft-ietf-tls-rfc3546bis-01.txt> <draft-ietf-tls-rfc3546bis-02.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667.
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 44 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire in November 2005. This Internet-Draft will expire in March 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This document describes extensions that may be used to add This document describes extensions that may be used to add
functionality to Transport Layer Security (TLS). It provides both functionality to Transport Layer Security (TLS). It provides both
generic extension mechanisms for the TLS handshake client and server generic extension mechanisms for the TLS handshake client and server
hellos, and specific extensions using these generic mechanisms. hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The The extensions may be used by TLS clients and servers. The
extensions are backwards compatible - communication is possible extensions are backwards compatible - communication is possible
between TLS 1.0 clients that support the extensions and TLS 1.0 between TLS clients that support the extensions and TLS
servers that do not support the extensions, and vice versa. servers that do not support the extensions, and vice versa.
Conventions used in this Document Conventions used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[KEYWORDS]. [KEYWORDS].
Table of Contents Table of Contents
skipping to change at page 3, line 51 skipping to change at page 3, line 51
the client certificate status information (e.g., an Online the client certificate status information (e.g., an Online
Certificate Status Protocol (OCSP) [OCSP] response) during a TLS Certificate Status Protocol (OCSP) [OCSP] response) during a TLS
handshake. This functionality is desirable in order to avoid handshake. This functionality is desirable in order to avoid
sending a Certificate Revocation List (CRL) over a constrained sending a Certificate Revocation List (CRL) over a constrained
access network and therefore save bandwidth. access network and therefore save bandwidth.
In order to support the extensions above, general extension In order to support the extensions above, general extension
mechanisms for the client hello message and the server hello message mechanisms for the client hello message and the server hello message
are introduced. are introduced.
The extensions described in this document may be used by TLS 1.0 The extensions described in this document may be used by TLS clients
clients and TLS 1.0 servers. The extensions are designed to be and servers. The extensions are designed to be backwards compatible
backwards compatible - meaning that TLS 1.0 clients that support the - meaning that TLS clients that support the extensions can talk to
extensions can talk to TLS 1.0 servers that do not support the TLS servers that do not support the extensions, and vice versa. The
extensions, and vice versa. document therefore updates TLS 1.0 [TLS] and TLS 1.1 [TLSbis].
Backwards compatibility is primarily achieved via two considerations: Backwards compatibility is primarily achieved via two considerations:
- Clients typically request the use of extensions via the extended - Clients typically request the use of extensions via the extended
client hello message described in Section 2.1. TLS 1.0 [TLS] client hello message described in Section 2.1. TLS requires
requires servers to accept extended client hello messages, even if servers to accept extended client hello messages, even if the
the server does not "understand" the extension. server does not "understand" the extension.
- For the specific extensions described here, no mandatory server - For the specific extensions described here, no mandatory server
response is required when clients request extended functionality. response is required when clients request extended functionality.
Essentially backwards compatibility is achieved based on the TLS
requirement that servers that are not "extensions-aware" ignore
data added to client hellos that they do not recognize -- see, for
example, Section 7.4.1.2 of [TLS].
Note however, that although backwards compatibility is supported, Note however, that although backwards compatibility is supported,
some constrained clients may be forced to reject communications with some constrained clients may be forced to reject communications with
servers that do not support the extensions as a result of the limited servers that do not support the extensions as a result of the limited
capabilities of such clients. capabilities of such clients.
This document is a revision of the RFC3546 [RFC3546]. The only This document is a revision of the RFC3546 [RFC3546]. The only
major change concerns the definition of new extensions. New major change concerns the definition of new extensions. New
extensions can now be defined via the IETF Consensus Process (rather extensions can now be defined via the IETF Consensus Process (rather
than requiring a standards track RFC). In addition, a few minor than requiring a standards track RFC). In addition, a few minor
clarifications and editorial improvements were made. clarifications and editorial improvements were made.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
describes general extension mechanisms for the client hello and describes general extension mechanisms for the client hello and
server hello handshake messages. Section 3 describes specific server hello handshake messages. Section 3 describes specific
extensions to TLS 1.0. Section 4 describes new error alerts for use extensions to TLS. Section 4 describes new error alerts for use
with the TLS extensions. The final sections of the document address with the TLS extensions. The final sections of the document address
IPR, security considerations, registration of the IPR, security considerations, registration of the
application/pkix-pkipath MIME type, acknowledgements, and references. application/pkix-pkipath MIME type, acknowledgements, and references.
2. General Extension Mechanisms 2. General Extension Mechanisms
This section presents general extension mechanisms for the TLS This section presents general extension mechanisms for the TLS
handshake client hello and server hello messages. handshake client hello and server hello messages.
These general extension mechanisms are necessary in order to enable These general extension mechanisms are necessary in order to enable
skipping to change at page 5, line 29 skipping to change at page 5, line 34
Here the new "client_hello_extension_list" field contains a list of Here the new "client_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section 2.3. extensions. The actual "Extension" format is defined in Section 2.3.
In the event that a client requests additional functionality using In the event that a client requests additional functionality using
the extended client hello, and this functionality is not supplied by the extended client hello, and this functionality is not supplied by
the server, the client MAY abort the handshake. the server, the client MAY abort the handshake.
Note that [TLS], Section 7.4.1.2, allows additional information to be 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 added to the client hello message. Thus the use of the extended
client hello defined above should not "break" existing TLS 1.0 client hello defined above should not "break" existing TLS servers.
servers.
A server that supports the extensions mechanism MUST accept only A server that supports the extensions mechanism MUST accept only
client hello messages in either the original or extended ClientHello client hello messages in either the original or extended ClientHello
format, and (as for all other messages) MUST check that the amount of format, and (as for all other messages) MUST check that the amount of
data in the message precisely matches one of these formats; if not data in the message precisely matches one of these formats; if not
then it MUST send a fatal "decode_error" alert. This overrides the then it MUST send a fatal "decode_error" alert. This overrides the
"Forward compatibility note" in [TLS]. "Forward compatibility note" in [TLS].
2.2. Extended Server Hello 2.2. Extended Server Hello
skipping to change at page 6, line 19 skipping to change at page 6, line 19
CipherSuite cipher_suite; CipherSuite cipher_suite;
CompressionMethod compression_method; CompressionMethod compression_method;
Extension server_hello_extension_list<0..2^16-1>; Extension server_hello_extension_list<0..2^16-1>;
} ServerHello; } ServerHello;
Here the new "server_hello_extension_list" field contains a list of Here the new "server_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section 2.3. extensions. The actual "Extension" format is defined in Section 2.3.
Note that the extended server hello message is only sent in response Note that the extended server hello message is only sent in response
to an extended client hello message. This prevents the possibility to an extended client hello message. This prevents the possibility
that the extended server hello message could "break" existing TLS 1.0 that the extended server hello message could "break" existing TLS
clients. clients.
2.3. Hello Extensions 2.3. Hello Extensions
The extension format for extended client hellos and extended server The extension format for extended client hellos and extended server
hellos is: hellos is:
struct { struct {
ExtensionType extension_type; ExtensionType extension_type;
opaque extension_data<0..2^16-1>; opaque extension_data<0..2^16-1>;
skipping to change at page 7, line 5 skipping to change at page 7, line 5
http://www.iana.org/assignments/tls-extensions). See sections 5 and http://www.iana.org/assignments/tls-extensions). See sections 5 and
8 for more information on how new values are added. 8 for more information on how new values are added.
Note that for all extension types (including those defined in Note that for all extension types (including those defined in
future), the extension type MUST NOT appear in the extended server future), the extension type MUST NOT appear in the extended server
hello unless the same extension type appeared in the corresponding hello unless the same extension type appeared in the corresponding
client hello. Thus clients MUST abort the handshake if they receive client hello. Thus clients MUST abort the handshake if they receive
an extension type in the extended server hello that they did not an extension type in the extended server hello that they did not
request in the associated (extended) client hello. request in the associated (extended) client hello.
Nonetheless "server initiated" extensions may be provided in the Nonetheless "server oriented" extensions may be provided in the
future within this framework - such an extension, say of type x, future within this framework - such an extension, say of type x,
would require the client to first send an extension of type x in the would require the client to first send an extension of type x in the
(extended) client hello with empty extension_data to indicate that it (extended) client hello with empty extension_data to indicate that it
supports the extension type. supports the extension type. In this case the client is offering the
capability to understand the extension type, and the server is taking
the client up on its offer.
Also note that when multiple extensions of different types are Also note that when multiple extensions of different types are
present in the extended client hello or the extended server hello, present in the extended client hello or the extended server hello,
the extensions may appear in any order. There MUST NOT be more than the extensions may appear in any order. There MUST NOT be more than
one extension of the same type. one extension of the same type.
Finally note that an extended client hello may be sent both when Finally note that an extended client hello may be sent both when
starting a new session and when requesting session resumption. starting a new session and when requesting session resumption.
Indeed a client that requests resumption of a session does not in Indeed a client that requests resumption of a session does not in
general know whether the server will accept this request, and general know whether the server will accept this request, and
skipping to change at page 9, line 7 skipping to change at page 9, line 7
extension to provide maximum fragment length negotiation. Section extension to provide maximum fragment length negotiation. Section
3.3 describes the extension to allow client certificate URLs. 3.3 describes the extension to allow client certificate URLs.
Section 3.4 describes the extension to allow a client to indicate Section 3.4 describes the extension to allow a client to indicate
which CA root keys it possesses. Section 3.5 describes the extension which CA root keys it possesses. Section 3.5 describes the extension
to allow the use of truncated HMAC. Section 3.6 describes the to allow the use of truncated HMAC. Section 3.6 describes the
extension to support integration of certificate status information extension to support integration of certificate status information
messages into TLS handshakes. messages into TLS handshakes.
3.1. Server Name Indication 3.1. Server Name Indication
[TLS] does not provide a mechanism for a client to tell a server the TLS does not provide a mechanism for a client to tell a server the
name of the server it is contacting. It may be desirable for clients name of the server it is contacting. It may be desirable for clients
to provide this information to facilitate secure connections to to provide this information to facilitate secure connections to
servers that host multiple 'virtual' servers at a single underlying servers that host multiple 'virtual' servers at a single underlying
network address. network address.
In order to provide the server name, clients MAY include an extension In order to provide the server name, clients MAY include an extension
of type "server_name" in the (extended) client hello. The of type "server_name" in the (extended) client hello. The
"extension_data" field of this extension SHALL contain "extension_data" field of this extension SHALL contain
"ServerNameList" where: "ServerNameList" where:
skipping to change at page 10, line 35 skipping to change at page 10, line 35
If an application negotiates a server name using an application If an application negotiates a server name using an application
protocol, then upgrades to TLS, and a server_name extension is sent, protocol, then upgrades to TLS, and a server_name extension is sent,
then the extension SHOULD contain the same name that was negotiated then the extension SHOULD contain the same name that was negotiated
in the application protocol. If the server_name is established in in the application protocol. If the server_name is established in
the TLS session handshake, the client SHOULD NOT attempt to request a the TLS session handshake, the client SHOULD NOT attempt to request a
different server name at the application layer. different server name at the application layer.
3.2. Maximum Fragment Length Negotiation 3.2. Maximum Fragment Length Negotiation
[TLS] specifies a fixed maximum plaintext fragment length of 2^14 Without this extension, TLS specifies a fixed maximum plaintext
bytes. It may be desirable for constrained clients to negotiate a fragment length of 2^14 bytes. It may be desirable for constrained
smaller maximum fragment length due to memory limitations or clients to negotiate a smaller maximum fragment length due to memory
bandwidth limitations. limitations or bandwidth limitations.
In order to negotiate smaller maximum fragment lengths, clients MAY In order to negotiate smaller maximum fragment lengths, clients MAY
include an extension of type "max_fragment_length" in the (extended) include an extension of type "max_fragment_length" in the (extended)
client hello. The "extension_data" field of this extension SHALL client hello. The "extension_data" field of this extension SHALL
contain: contain:
enum{ enum{
2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength; } MaxFragmentLength;
skipping to change at page 11, line 45 skipping to change at page 11, line 45
defined in [TLS], [KERB], and [AESSUITES]), and when null compression defined in [TLS], [KERB], and [AESSUITES]), and when null compression
is used, the record layer output can be at most 793 bytes: 5 bytes of is used, 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 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 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 receiving a TLS record layer message larger than 793 bytes may
discard the message and send a "record_overflow" alert, without discard the message and send a "record_overflow" alert, without
decrypting the message. decrypting the message.
3.3. Client Certificate URLs 3.3. Client Certificate URLs
[TLS] specifies that when client authentication is performed, client Without this extension, TLS specifies that when client authentication
certificates are sent by clients to servers during the TLS handshake. is performed, client certificates are sent by clients to servers during
It may be desirable for constrained clients to send certificate URLs the TLS handshake. It may be desirable for constrained clients to send
in place of certificates, so that they do not need to store their certificate URLs in place of certificates, so that they do not need to
certificates and can therefore save memory. store their certificates and can therefore save memory.
In order to negotiate to send certificate URLs to a server, clients In order to negotiate to send certificate URLs to a server, clients
MAY include an extension of type "client_certificate_url" in the MAY include an extension of type "client_certificate_url" in the
(extended) client hello. The "extension_data" field of this (extended) client hello. The "extension_data" field of this
extension SHALL be empty. extension SHALL be empty.
(Note that it is necessary to negotiate use of client certificate (Note that it is necessary to negotiate use of client certificate
URLs in order to avoid "breaking" existing TLS 1.0 servers.) URLs in order to avoid "breaking" existing TLS servers.)
Servers that receive an extended client hello containing a Servers that receive an extended client hello containing a
"client_certificate_url" extension, MAY indicate that they are "client_certificate_url" extension, MAY indicate that they are
willing to accept certificate URLs by including an extension of type willing to accept certificate URLs by including an extension of type
"client_certificate_url" in the (extended) server hello. The "client_certificate_url" in the (extended) server hello. The
"extension_data" field of this extension SHALL be empty. "extension_data" field of this extension SHALL be empty.
After negotiation of the use of client certificate URLs has been After negotiation of the use of client certificate URLs has been
successfully completed (by exchanging hellos including successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients MAY send a "client_certificate_url" extensions), clients MAY send a
skipping to change at page 13, line 39 skipping to change at page 13, line 33
root certificate MAY be omitted from the chain, under the assumption root certificate MAY be omitted from the chain, under the assumption
that the server must already possess it in order to validate it. that the server must already possess it in order to validate it.
Servers receiving "CertificateURL" SHALL attempt to retrieve the Servers receiving "CertificateURL" SHALL attempt to retrieve the
client's certificate chain from the URLs, and then process the client's certificate chain from the URLs, and then process the
certificate chain as usual. A cached copy of the content of any URL 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 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. that URL and it matches the hash of the cached copy.
Servers that support this extension MUST support the http: URL scheme Servers that support this extension MUST support the http: URL scheme
for certificate URLs, and MAY support other schemes. for certificate URLs, and MAY support other schemes. Use of other
schemes than "http", "https", or "ftp" may create unexpected
problems.
If the protocol used is HTTP, then the HTTP server can be configured
to use the Cache-Control and Expires directives described in [HTTP]
to specify whether and for how long certificates or certificate
chains should be cached.
The TLS server is not required to follow HTTP redirects when
retrieving the certificates or certificate chain. The URLs used in
this extension SHOULD therefore be chosen not to depend on such
redirects.
If the protocol used to retrieve certificates or certificate chains If the protocol used to retrieve certificates or certificate chains
returns a MIME formatted response (as HTTP does), then the following returns a MIME formatted response (as HTTP does), then the following
MIME Content-Types SHALL be used: when a single X.509v3 certificate MIME Content-Types SHALL be used: when a single X.509v3 certificate
is returned, the Content-Type is "application/pkix-cert" [PKIOP], and is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
when a chain of X.509v3 certificates is returned, the Content-Type is when a chain of X.509v3 certificates is returned, the Content-Type is
"application/pkix-pkipath" (see Section 8). "application/pkix-pkipath" (see Section 8).
If a SHA-1 hash is present for an URL, then the server MUST check 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 that the SHA-1 hash of the contents of the object retrieved from that
skipping to change at page 21, line 25 skipping to change at page 21, line 25
Security considerations for the extension mechanism in general, and Security considerations for the extension mechanism in general, and
the design of new extensions, are described in the previous section. the design of new extensions, are described in the previous section.
A security analysis of each of the extensions defined in this A security analysis of each of the extensions defined in this
document is given below. document is given below.
In general, implementers should continue to monitor the state of the In general, implementers should continue to monitor the state of the
art, and address any weaknesses identified. art, and address any weaknesses identified.
Additional security considerations are described in the TLS 1.0 RFC Additional security considerations are described in the TLS 1.0 RFC
[TLS]. [TLS] and the TLS 1.1 RFC [TLSbis].
6.1. Security of server_name 6.1. Security of server_name
If a single server hosts several domains, then clearly it is If a single server hosts several domains, then clearly it is
necessary for the owners of each domain to ensure that this satisfies necessary for the owners of each domain to ensure that this satisfies
their security needs. Apart from this, server_name does not appear their security needs. Apart from this, server_name does not appear
to introduce significant security issues. to introduce significant security issues.
Implementations MUST ensure that a buffer overflow does not occur Implementations MUST ensure that a buffer overflow does not occur
whatever the values of the length fields in server_name. whatever the values of the length fields in server_name.
skipping to change at page 21, line 50 skipping to change at page 21, line 50
hostnames in TLS - in particular, the consequences of "spoofed" names hostnames in TLS - in particular, the consequences of "spoofed" names
that are indistinguishable from another name when displayed or that are indistinguishable from another name when displayed or
printed. It is recommended that server certificates not be issued printed. It is recommended that server certificates not be issued
for internationalized hostnames unless procedures are in place to for internationalized hostnames unless procedures are in place to
mitigate the risk of spoofed hostnames. mitigate the risk of spoofed hostnames.
6.2. Security of max_fragment_length 6.2. Security of max_fragment_length
The maximum fragment length takes effect immediately, including for The maximum fragment length takes effect immediately, including for
handshake messages. However, that does not introduce any security handshake messages. However, that does not introduce any security
complications that are not already present in TLS, since [TLS] complications that are not already present in TLS, since TLS
requires implementations to be able to handle fragmented handshake requires implementations to be able to handle fragmented handshake
messages. messages.
Note that as described in section 3.2, once a non-null cipher suite Note that as described in section 3.2, once a non-null cipher suite
has been activated, the effective maximum fragment length depends on has been activated, the effective maximum fragment length depends on
the cipher suite and compression method, as well as on the negotiated the cipher suite and compression method, as well as on the negotiated
max_fragment_length. This must be taken into account when sizing max_fragment_length. This must be taken into account when sizing
buffers, and checking for buffer overflow. buffers, and checking for buffer overflow.
6.3. Security of client_certificate_url 6.3. Security of client_certificate_url
skipping to change at page 24, line 43 skipping to change at page 24, line 43
None of the extensions defined here directly use strings subject to None of the extensions defined here directly use strings subject to
localization. Domain Name System (DNS) hostnames are encoded using localization. Domain Name System (DNS) hostnames are encoded using
UTF-8. If future extensions use text strings, then UTF-8. If future extensions use text strings, then
internationalization should be considered in their design. internationalization should be considered in their design.
8. IANA Considerations 8. IANA Considerations
Sections 2.3 and 5 describes a registry of ExtensionType values to be Sections 2.3 and 5 describes a registry of ExtensionType values to be
maintained by the IANA. ExtensionType values are to be assigned via maintained by the IANA. ExtensionType values are to be assigned via
IETF Consensus as defined in RFC 2434 [IANA]. IETF Consensus as defined in RFC 2434 [IANA]. The initial registry
corresponds to the definition of "ExtensionType" in Section 2.3.
The MIME type "application/pkix-pkipath" has been registered by the The MIME type "application/pkix-pkipath" has been registered by the
IANA with the following template: IANA with the following template:
To: ietf-types@iana.org Subject: Registration of MIME media type To: ietf-types@iana.org Subject: Registration of MIME media type
application/pkix-pkipath application/pkix-pkipath
MIME media type name: application MIME media type name: application
MIME subtype name: pkix-pkipath MIME subtype name: pkix-pkipath
Required parameters: none Required parameters: none
Optional parameters: version (default value is "1") Optional parameters: version (default value is "1")
Encoding considerations: Encoding considerations:
This MIME type is a DER encoding of the ASN.1 type PkiPath, This MIME type is a DER encoding of the ASN.1 type PkiPath,
defined as follows: defined as follows:
PkiPath ::= SEQUENCE OF Certificate PkiPath ::= SEQUENCE OF Certificate
PkiPath is used to represent a certification path. Within the PkiPath is used to represent a certification path. Within the
sequence, the order of certificates is such that the subject of sequence, the order of certificates is such that the subject of
the first certificate is the issuer of the second certificate, the first certificate is the issuer of the second certificate,
skipping to change at page 26, line 17 skipping to change at page 26, line 17
Further parsing is required to distinguish from other ASN.1 Further parsing is required to distinguish from other ASN.1
types. types.
File extension(s): .pkipath File extension(s): .pkipath
Macintosh File Type Code(s): not specified Macintosh File Type Code(s): not specified
Person & email address to contact for further information: Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com> Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: Change controller:
Magnus Nystrom <magnus@rsasecurity.com> IESG <iesg@ietf.org>
9. Intellectual Property Rights 9. Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights such rights. Information on the procedures with respect to rights
skipping to change at page 27, line 43 skipping to change at page 27, line 37
RFC 2585, May 1999. RFC 2585, May 1999.
[PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet [PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
Public Key Infrastructure - Certificate and Public Key Infrastructure - Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999. 1.0", RFC 2246, January 1999.
[TLSbis] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", IETF TLS WG Internet-draft,
draft-ietf-tls-rfc2246-bis-13.txt, June 2005.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, [URI] Berners-Lee, T., Fielding, R. and L. Masinter,
"Uniform Resource Identifiers (URI): Generic Syntax", "Uniform Resource Identifiers (URI): Generic Syntax",
RFC 2396, August 1998. RFC 2396, August 1998.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003. 10646", RFC 3629, November 2003.
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-
8:2001, "Information Systems - Open Systems 8:2001, "Information Systems - Open Systems
Interconnection - The Directory: Public key and Interconnection - The Directory: Public key and
 End of changes. 27 change blocks. 
42 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/