draft-ietf-tls-cached-info-12.txt   draft-ietf-tls-cached-info-13.txt 
TLS S. Santesson TLS S. Santesson
Internet-Draft 3xA Security AB Internet-Draft 3xA Security AB
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: January 16, 2013 Nokia Siemens Networks Expires: March 16, 2013 Nokia Siemens Networks
July 15, 2012 September 12, 2012
Transport Layer Security (TLS) Cached Information Extension Transport Layer Security (TLS) Cached Information Extension
draft-ietf-tls-cached-info-12.txt draft-ietf-tls-cached-info-13.txt
Abstract Abstract
Transport Layer Security (TLS) handshakes often include fairly static Transport Layer Security (TLS) handshakes often include fairly static
information, such as the server certificate and a list of trusted information, such as the server certificate and a list of trusted
Certification Authorities (CAs). This information can be of Certification Authorities (CAs). This information can be of
considerable size, particularly if the server certificate is bundled considerable size, particularly if the server certificate is bundled
with a complete certificate path (including all intermediary with a complete certificate path (including all intermediary
certificates up to the trust anchor public key). certificates up to the trust anchor public key).
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 16, 2013. This Internet-Draft will expire on March 16, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 15 skipping to change at page 8, line 15
opaque ASN.1Cert<1..2^24-1>; opaque ASN.1Cert<1..2^24-1>;
struct { struct {
ASN.1Cert certificate_list<0..2^24-1>; ASN.1Cert certificate_list<0..2^24-1>;
} Certificate; } Certificate;
By using the extension defined in this document the following By using the extension defined in this document the following
information is sent: information is sent:
struct { struct {
CachedObject ASN.1Cert<1..2^24-1>; CachedObject cached_objects<1..2^24-1>;
} Certificate; } Certificate;
The opaque ASN.1Cert structure is replaced with the CachedObject The certificate_list vector of opaque ASN.1Cert elements in the
structure defined in this document. original syntax is replaced with a vector holding CachedObject
structures as defined in this document.
Note: [I-D.ietf-tls-oob-pubkey] allows a PKIX certificate containing Note: [I-D.ietf-tls-oob-pubkey] allows a PKIX certificate containing
only the SubjectPublicKeyInfo instead of the full information only the SubjectPublicKeyInfo instead of the full information
typically found in a certificate. Hence, when this specification is typically found in a certificate. Hence, when this specification is
used in combination with [I-D.ietf-tls-oob-pubkey] and the negotiated used in combination with [I-D.ietf-tls-oob-pubkey] and the negotiated
certificate type is a raw public key then the TLS server sends the certificate type is a raw public key then the TLS server sends the
hashed Certificate payload that contains a ASN.1Cert structure of the hashed Certificate payload that contains a ASN.1Cert structure of the
SubjectPublicKeyInfo. SubjectPublicKeyInfo.
4.2. Fingerprint for Trusted CAs 4.2. Fingerprint for Trusted CAs
skipping to change at page 9, line 9 skipping to change at page 9, line 10
DistinguishedName certificate_authorities<0..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest; } CertificateRequest;
By using the extension defined in this document the following By using the extension defined in this document the following
information is sent: information is sent:
struct { struct {
ClientCertificateType certificate_types<1..2^8-1>; ClientCertificateType certificate_types<1..2^8-1>;
SignatureAndHashAlgorithm SignatureAndHashAlgorithm
supported_signature_algorithms<2^16-1>; supported_signature_algorithms<2^16-1>;
CachedObject DistinguishedName<1..2^16-1>; CachedObject cached_objects<1..2^16-1>;
} CertificateRequest; } CertificateRequest;
The opaque DistinguishedName structure is replaced with the The certificate_authorities vector of opaque DistinguishedName
CachedObject structure defined in this document. elements in the original syntax is replaced with a vector holding
CachedObject structures as defined in this document.
5. Example 5. Example
Figure 1 illustrates an example exchange using the TLS cached info Figure 1 illustrates an example exchange using the TLS cached info
extension. In the normal TLS handshake exchange shown in flow (A) extension. In the normal TLS handshake exchange shown in flow (A)
the TLS server provides its certificate in the Certificate payload to the TLS server provides its certificate in the Certificate payload to
the client, see step [1]. This allows the client to store the the client, see step [1]. This allows the client to store the
certificate for future use. After some time the TLS client again certificate for future use. After some time the TLS client again
interacts with the same TLS server and makes use of the TLS cached interacts with the same TLS server and makes use of the TLS cached
info extension, as shown in flow (B). The TLS client indicates info extension, as shown in flow (B). The TLS client indicates
skipping to change at page 15, line 25 skipping to change at page 15, line 25
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
9.2. Informative References 9.2. Informative References
[I-D.ietf-tls-oob-pubkey] [I-D.ietf-tls-oob-pubkey]
Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H. Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H.
Tschofenig, "TLS Out-of-Band Public Key Validation", Tschofenig, "Out-of-Band Public Key Validation for
draft-ietf-tls-oob-pubkey-03 (work in progress), Transport Layer Security", draft-ietf-tls-oob-pubkey-04
April 2012. (work in progress), July 2012.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object
Workshop", RFC 6574, April 2012. Workshop", RFC 6574, April 2012.
Authors' Addresses Authors' Addresses
 End of changes. 8 change blocks. 
13 lines changed or deleted 15 lines changed or added

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