draft-ietf-tls-cached-info-22.txt   draft-ietf-tls-cached-info-23.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: July 29, 2016 ARM Ltd. Expires: November 12, 2016 ARM Ltd.
January 26, 2016 May 11, 2016
Transport Layer Security (TLS) Cached Information Extension Transport Layer Security (TLS) Cached Information Extension
draft-ietf-tls-cached-info-22.txt draft-ietf-tls-cached-info-23.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 chain (i.e., the certificates of with a complete certificate chain (i.e., the certificates of
intermediate CAs up to the root CA). intermediate CAs up to the root CA).
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 July 29, 2016. This Internet-Draft will expire on November 12, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 25 skipping to change at page 2, line 25
3. Cached Information Extension . . . . . . . . . . . . . . . . 3 3. Cached Information Extension . . . . . . . . . . . . . . . . 3
4. Exchange Specification . . . . . . . . . . . . . . . . . . . 5 4. Exchange Specification . . . . . . . . . . . . . . . . . . . 5
4.1. Server Certificate Message . . . . . . . . . . . . . . . 5 4.1. Server Certificate Message . . . . . . . . . . . . . . . 5
4.2. CertificateRequest Message . . . . . . . . . . . . . . . 6 4.2. CertificateRequest Message . . . . . . . . . . . . . . . 6
5. Fingerprint Calculation . . . . . . . . . . . . . . . . . . . 7 5. Fingerprint Calculation . . . . . . . . . . . . . . . . . . . 7
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8.1. New Entry to the TLS ExtensionType Registry . . . . . . . 10 8.1. New Entry to the TLS ExtensionType Registry . . . . . . . 10
8.2. New Registry for CachedInformationType . . . . . . . . . 10 8.2. New Registry for CachedInformationType . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Reducing the amount of information exchanged during a Transport Layer Reducing the amount of information exchanged during a Transport Layer
Security handshake to a minimum helps to improve performance in Security handshake to a minimum helps to improve performance in
environments where devices are connected to a network with a low environments where devices are connected to a network with a low
bandwidth, and lossy radio technology. With Internet of Things such bandwidth, and lossy radio technology. With Internet of Things such
environments exist, for example, when devices use IEEE 802.15.4 or environments exist, for example, when devices use IEEE 802.15.4 or
Bluetooth Smart. For more information about the challenges with Bluetooth Smart. For more information about the challenges with
smart object deployments please see [RFC6574]. smart object deployments please see [RFC6574].
skipping to change at page 3, line 26 skipping to change at page 3, line 26
This document refers to the TLS protocol but the description is This document refers to the TLS protocol but the description is
equally applicable to DTLS as well. equally applicable to DTLS as well.
3. Cached Information Extension 3. Cached Information Extension
This document defines a new extension type (cached_info(TBD)), which This document defines a new extension type (cached_info(TBD)), which
is used in client hello and server hello messages. The extension is used in client hello and server hello messages. The extension
type is specified as follows. type is specified as follows.
enum { enum {
cached_info(TBD), (65535) cached_info(TBD), (65535)
} ExtensionType; } ExtensionType;
The extension_data field of this extension, when included in the The extension_data field of this extension, when included in the
client hello, MUST contain the CachedInformation structure. The client hello, MUST contain the CachedInformation structure. The
client MAY send multiple CachedObjects of the same client MAY send multiple CachedObjects of the same
CachedInformationType. This may, for example, be the case when the CachedInformationType. This may, for example, be the case when the
client has cached multiple certificates from a server. client has cached multiple certificates from a server.
enum { enum {
cert(1), cert_req(2) (255) cert(1), cert_req(2) (255)
} CachedInformationType; } CachedInformationType;
struct { struct {
select (type) { select (type) {
case client: case client:
CachedInformationType type; CachedInformationType type;
opaque hash_value[4]; opaque hash_value<1..255>;
case server: case server:
CachedInformationType type; CachedInformationType type;
}; } body;
} CachedObject; } CachedObject;
struct { struct {
CachedObject cached_info<1..255>; CachedObject cached_info<1..2^16-1>;
} CachedInformation; } CachedInformation;
This document defines the following two types: This document defines the following two types:
'cert' Type for not sending the complete Server Certificate Message: 'cert' Type for not sending the complete Server Certificate Message:
With the type field set to 'cert', the client MUST include the With the type field set to 'cert', the client MUST include the
fingerprint of the Certificate message in the hash_value field. fingerprint of the Certificate message in the hash_value field.
For this type the fingerprint MUST be calculated using the For this type the fingerprint MUST be calculated using the
procedure described in Section 5 with the Certificate message as procedure described in Section 5 with the Certificate message as
input data. input data.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
'cert_req' Type for not sending the complete CertificateRequest 'cert_req' Type for not sending the complete CertificateRequest
Message: Message:
With the type set to 'cert_req', the client MUST include the With the type set to 'cert_req', the client MUST include the
fingerprint of the CertificateRequest message in the hash_value fingerprint of the CertificateRequest message in the hash_value
field. For this type the fingerprint MUST be calculated using the field. For this type the fingerprint MUST be calculated using the
procedure described in Section 5 with the CertificateRequest procedure described in Section 5 with the CertificateRequest
message as input data. message as input data.
New cached info types can be added following the policy described in New cached info types can be added following the policy described in
the IANA considerations section, see Section 8. New hash algorithms the IANA considerations section, see Section 8. New message digest
can also be added by registering a new type. For practical reasons algorithms for use with these types can also be added by registering
we recommend to re-use hash algorithms already available with TLS a new type that makes use of the updated message digest algorithm.
ciphersuites to avoid additional code and to keep the collision For practical reasons we recommend to re-use hash algorithms already
probably low new hash algorithms MUST NOT have a collision resistance available with TLS ciphersuites to avoid additional code and to keep
worse than SHA-256 when truncated to 4 bytes. the collision probably low new hash algorithms MUST NOT have a
collision resistance worse than SHA-256.
4. Exchange Specification 4. Exchange Specification
Clients supporting this extension MAY include the "cached_info" Clients supporting this extension MAY include the "cached_info"
extension in the (extended) client hello. If the client includes the extension in the (extended) client hello. If the client includes the
extension then it MUST contain one or more CachedObject attributes. extension then it MUST contain one or more CachedObject attributes.
A server supporting this extension MAY include the "cached_info" A server supporting this extension MAY include the "cached_info"
extension in the (extended) server hello. By returning the extension in the (extended) server hello. By returning the
"cached_info" extension the server indicates that it supports the "cached_info" extension the server indicates that it supports the
skipping to change at page 6, line 35 skipping to change at page 6, line 35
Note: We assume that the server implementation is able to select the Note: We assume that the server implementation is able to select the
appropriate certificate or SubjectPublicKeyInfo from the received appropriate certificate or SubjectPublicKeyInfo from the received
hash value. If the SNI extension is used by the client then the hash value. If the SNI extension is used by the client then the
server has additional information to guide the selection of the server has additional information to guide the selection of the
appropriate cached info. appropriate cached info.
When the cached info specification is used then a modified version of When the cached info specification is used then a modified version of
the Certificate message is exchanged. The modified structure is the Certificate message is exchanged. The modified structure is
shown in Figure 1. shown in Figure 1.
struct { struct {
opaque hash_value[4]; opaque hash_value<1..255>;
} Certificate; } Certificate;
Figure 1: Cached Info Certificate Message. Figure 1: Cached Info Certificate Message.
4.2. CertificateRequest Message 4.2. CertificateRequest Message
When a fingerprint for an object of type 'cert_req' is provided in When a fingerprint for an object of type 'cert_req' is provided in
the client hello, the server MAY send the CertificateRequest message the client hello, the server MAY send the CertificateRequest message
shown in Figure 2 message under the following conditions: shown in Figure 2 message under the following conditions:
o The server software implements the "cached_info" extension defined o The server software implements the "cached_info" extension defined
skipping to change at page 7, line 18 skipping to change at page 7, line 18
check ensures that the information cached by the client is check ensures that the information cached by the client is
current. The procedure for calculating the fingerprint is current. The procedure for calculating the fingerprint is
described in Section 5. described in Section 5.
o The server wants to request a certificate from the client. o The server wants to request a certificate from the client.
The original CertificateRequest handshake message syntax is defined The original CertificateRequest handshake message syntax is defined
in [RFC5246]. The modified structure of the CertificateRequest in [RFC5246]. The modified structure of the CertificateRequest
message is shown in Figure 2. message is shown in Figure 2.
struct { struct {
opaque hash_value[4]; opaque hash_value<1..255>;
} CertificateRequest; } CertificateRequest;
Figure 2: Cached Info CertificateRequest Message. Figure 2: Cached Info CertificateRequest Message.
The CertificateRequest payload is the input parameter to the The CertificateRequest payload is the input parameter to the
fingerprint calculation described in Section 5. fingerprint calculation described in Section 5.
5. Fingerprint Calculation 5. Fingerprint Calculation
The fingerprint MUST be computed as follows: The fingerprint for the two cached info objects defined in this
document MUST be computed as follows:
1. Compute the SHA-256 [RFC6234] hash of the input data. The input 1. Compute the SHA-256 [RFC6234] hash of the input data. The input
data depends on the cached info type. This document defines two data depends on the cached info type. This document defines two
cached info types, described in Section 4.1 and in Section 4.2. cached info types, described in Section 4.1 and in Section 4.2.
Note that the computed hash only covers the input data structure Note that the computed hash only covers the input data structure
(and not any type and length information of the record layer). (and not any type and length information of the record layer).
Appendix A shows an example. Appendix A shows an example.
2. Truncate the output of the SHA-256 hash. When a hash value is 2. Use the output of the SHA-256 hash.
truncated to 32 bits, the leftmost 32 bits (that is, the most
significant 32 bits in network byte order) from the binary
representation of the hash value MUST be used as the truncated
value. An example of a 256-bit hash output truncated to 32 bits
is shown in Figure 3.
256-bit hash:
0x265357902fe1b7e2a04b897c6025d7a2265357902fe1b7e2a04b897c6025d7a2
32-bit truncated hash:
0x26535790
Figure 3: Truncated Hash Example.
The purpose of the fingerprint provided by the client is to help the The purpose of the fingerprint provided by the client is to help the
server select the correct information. For example, in case of the server select the correct information. For example, in case of the
certificate message the fingerprint identifies the server certificate certificate message the fingerprint identifies the server certificate
(and the corresponding private key) for use for with the rest of the (and the corresponding private key) for use for with the rest of the
handshake. Servers may have more than one certificate and therefore handshake. Servers may have more than one certificate and therefore
a hash needs to be long enough to keep the probably of hash a hash needs to be long enough to keep the probably of hash
collisions low. On the other hand, the cached info design aims to collisions low. On the other hand, the cached info design aims to
reduce the amount of data being exchanged. The security of the reduce the amount of data being exchanged. The security of the
handshake depends on the private key and not on the size of the handshake depends on the private key and not on the size of the
skipping to change at page 8, line 36 skipping to change at page 8, line 16
has to fall back to a full exchange. (2) If the attacker manages to has to fall back to a full exchange. (2) If the attacker manages to
inject a fingerprint that refers to data the client has not cached inject a fingerprint that refers to data the client has not cached
then the exchange will fail later when the client continues with the then the exchange will fail later when the client continues with the
handshake and aims to verify the digital signature. The signature handshake and aims to verify the digital signature. The signature
verification will fail since the public key cached by the client will verification will fail since the public key cached by the client will
not correspond to the private key that was used by server to sign the not correspond to the private key that was used by server to sign the
message. message.
6. Example 6. Example
In the regular, full TLS handshake exchange, shown in Figure 4, the In the regular, full TLS handshake exchange, shown in Figure 3, 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 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 Figure 5. The TLS client indicates info extension, as shown in Figure 4. The TLS client indicates
support for this specification via the "cached_info" extension, see support for this specification via the "cached_info" extension, see
step (2), and indicates that it has stored the certificate from the step (2), and indicates that it has stored the certificate from the
earlier exchange (by indicating the 'cert' type). With step (3) the earlier exchange (by indicating the 'cert' type). With step (3) the
TLS server acknowledges the supports of the 'cert' type and by TLS server acknowledges the supports of the 'cert' type and by
including the value in the server hello informs the client that the including the value in the server hello informs the client that the
content of the certificate payload contains the fingerprint of the content of the certificate payload contains the fingerprint of the
certificate instead of the RFC 5246-defined payload of the certificate instead of the RFC 5246-defined payload of the
certificate message in step (4). certificate message in step (4).
ClientHello -> ClientHello ->
skipping to change at page 9, line 23 skipping to change at page 8, line 49
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished -> Finished ->
<- [ChangeCipherSpec] <- [ChangeCipherSpec]
Finished Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 4: Example Message Exchange: Initial (full) Exchange. Figure 3: Example Message Exchange: Initial (full) Exchange.
ClientHello ClientHello
cached_info=(cert) -> // (2) cached_info=(cert) -> // (2)
<- ServerHello <- ServerHello
cached_info=(cert) (3) cached_info=(cert) (3)
Certificate (4) Certificate (4)
ServerKeyExchange* ServerKeyExchange*
ServerHelloDone ServerHelloDone
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
[ChangeCipherSpec] [ChangeCipherSpec]
Finished -> Finished ->
<- [ChangeCipherSpec] <- [ChangeCipherSpec]
Finished Finished
Application Data <-------> Application Data Application Data <-------> Application Data
Figure 5: Example Message Exchange: TLS Cached Extension Usage. Figure 4: Example Message Exchange: TLS Cached Extension Usage.
7. Security Considerations 7. Security Considerations
This specification defines a mechanism to reference stored state This specification defines a mechanism to reference stored state
using a fingerprint. Sending a fingerprint of cached information in using a fingerprint. Sending a fingerprint of cached information in
an unencrypted handshake, as the client and server hello is, may an unencrypted handshake, as the client and server hello is, may
allow an attacker or observer to correlate independent TLS exchanges. allow an attacker or observer to correlate independent TLS exchanges.
While some information elements used in this specification, such as While some information elements used in this specification, such as
server certificates, are public objects and usually do not contain server certificates, are public objects and usually do not contain
sensitive information, other not yet defined types may. Those who sensitive information, other not yet defined types may. Those who
skipping to change at page 11, line 24 skipping to change at page 11, line 4
o Ondrej Mikle (March 2012) o Ondrej Mikle (March 2012)
o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014) o Ilari Liusvaara, Adam Langley, and Eric Rescorla (July 2014)
o Sean Turner (August 2014) o Sean Turner (August 2014)
o Martin Thomson (August 2015) o Martin Thomson (August 2015)
o Jouni Korhonen (November 2015) o Jouni Korhonen (November 2015)
o Matt Miller (December 2015) o Matt Miller (December 2015)
o Dave Garrett (December 2015)
We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp
Bagaria and Eric Rescorla for their feedback regarding the Bagaria and Eric Rescorla for their feedback regarding the
fingerprint calculation. fingerprint calculation.
Finally, we would like to thank the TLS working group chairs, Sean Finally, we would like to thank the TLS working group chairs, Sean
Turner and Joe Salowey, as well as the responsible security area Turner and Joe Salowey, as well as the responsible security area
director, Stephen Farrell, for their support and their reviews. director, Stephen Farrell, for their support and their reviews.
10. References 10. References
skipping to change at page 12, line 40 skipping to change at page 12, line 15
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <http://www.rfc-editor.org/info/rfc7250>.
Appendix A. Example Appendix A. Example
Consider a certificate containing an NIST P256 elliptic curve public Consider a certificate containing an NIST P256 elliptic curve public
key displayed using Peter Gutmann's ASN.1 decoder [ASN.1-Dump] in key displayed using Peter Gutmann's ASN.1 decoder [ASN.1-Dump] in
Figure 6. Figure 5.
0 556: SEQUENCE { 0 556: SEQUENCE {
4 434: SEQUENCE { 4 434: SEQUENCE {
8 3: [0] { 8 3: [0] {
10 1: INTEGER 2 10 1: INTEGER 2
: } : }
13 1: INTEGER 13 13 1: INTEGER 13
16 10: SEQUENCE { 16 10: SEQUENCE {
18 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 18 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2)
: } : }
skipping to change at page 14, line 33 skipping to change at page 14, line 7
308 20: OCTET STRING 308 20: OCTET STRING
: 7A 00 5F 86 64 FC E0 5D E5 11 10 3B B2 E6 3B C4 : 7A 00 5F 86 64 FC E0 5D E5 11 10 3B B2 E6 3B C4
: 26 3F CF E2 : 26 3F CF E2
: } : }
: } : }
330 110: SEQUENCE { 330 110: SEQUENCE {
332 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 332 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
337 103: OCTET STRING, encapsulates { 337 103: OCTET STRING, encapsulates {
339 101: SEQUENCE { 339 101: SEQUENCE {
341 20: [0] 341 20: [0]
: 9D 6D 20 24 49 01 3F 2B CB 78 B5 19 BC 7E 24 C9 : 9D 6D 20 24 49 01 3F 2B CB 78 B5 19 BC 7E 24
: DB FB 36 7C : C9 DB FB 36 7C
363 66: [1] { 363 66: [1] {
365 64: [4] { 365 64: [4] {
367 62: SEQUENCE { 367 62: SEQUENCE {
369 11: SET { 369 11: SET {
371 9: SEQUENCE { 371 9: SEQUENCE {
373 3: OBJECT IDENTIFIER countryName (2 5 4 6) 373 3: OBJECT IDENTIFIER countryName (2 5 4 6)
378 2: PrintableString 'NL' 378 2: PrintableString 'NL'
: } : }
: } : }
382 17: SET { 382 17: SET {
skipping to change at page 15, line 36 skipping to change at page 15, line 11
: 65 8E 1A C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 : 65 8E 1A C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20
509 49: INTEGER 509 49: INTEGER
: 00 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA : 00 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA
: 54 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC : 54 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC
: 42 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 : 42 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57
: 45 : 45
: } : }
: } : }
: } : }
Figure 6: ASN.1-based Certificate: Example. Figure 5: ASN.1-based Certificate: Example.
To include the certificate shown in Figure 6 in a TLS/DTLS To include the certificate shown in Figure 5 in a TLS/DTLS
Certificate message it is prepended with a message header. This Certificate message it is prepended with a message header. This
Certificate message header in our example is 0b 00 02 36 00 02 33 00 Certificate message header in our example is 0b 00 02 36 00 02 33 00
02 00 02 30, which indicates: 02 00 02 30, which indicates:
Message Type: 0b -- 1 byte type field indicating a Certificate Message Type: 0b -- 1 byte type field indicating a Certificate
message message
Length: 00 02 36 -- 3 byte length field indicating a 566 bytes Length: 00 02 36 -- 3 byte length field indicating a 566 bytes
payload payload
Certificates Length: 00 02 33 -- 3 byte length field indicating 563 Certificates Length: 00 02 33 -- 3 byte length field indicating 563
bytes for the entire certificates_list structure, which may bytes for the entire certificates_list structure, which may
contain multiple certificates. In our example only one contain multiple certificates. In our example only one
certificate is included. certificate is included.
Certificate Length: 00 02 30 -- 3 byte length field indicating 560 Certificate Length: 00 02 30 -- 3 byte length field indicating 560
bytes of the actual certificate following immediately afterwards. bytes of the actual certificate following immediately afterwards.
In our example, this is the certificate content with 30 82 02 .... In our example, this is the certificate content with 30 82 02 ....
9E 57 45 shown in Figure 7. 9E 57 45 shown in Figure 6.
The hex encoding of the ASN.1 encoded certificate payload shown in The hex encoding of the ASN.1 encoded certificate payload shown in
Figure 6 leads to the following encoding. Figure 5 leads to the following encoding.
30 82 02 2C 30 82 01 B2 A0 03 02 01 02 02 01 0D 30 82 02 2C 30 82 01 B2 A0 03 02 01 02 02 01 0D
30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 3E 31 0B 30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 3E 31 0B
30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06
03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1C 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1C
30 1A 06 03 55 04 03 13 13 50 6F 6C 61 72 73 73 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 72 73 73
6C 20 54 65 73 74 20 45 43 20 43 41 30 1E 17 0D 6C 20 54 65 73 74 20 45 43 20 43 41 30 1E 17 0D
31 33 30 39 32 34 31 35 35 32 30 34 5A 17 0D 32 31 33 30 39 32 34 31 35 35 32 30 34 5A 17 0D 32
33 30 39 32 32 31 35 35 32 30 34 5A 30 41 31 0B 33 30 39 32 32 31 35 35 32 30 34 5A 30 41 31 0B
30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06
skipping to change at page 17, line 41 skipping to change at page 16, line 41
72 73 73 6C 20 54 65 73 74 20 45 43 20 43 41 82 72 73 73 6C 20 54 65 73 74 20 45 43 20 43 41 82
09 00 C1 43 E2 7E 62 43 CC E8 30 0A 06 08 2A 86 09 00 C1 43 E2 7E 62 43 CC E8 30 0A 06 08 2A 86
48 CE 3D 04 03 02 03 68 00 30 65 02 30 4A 65 0D 48 CE 3D 04 03 02 03 68 00 30 65 02 30 4A 65 0D
7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D BB 70 4C 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D BB 70 4C
96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 65 8E 1A 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 65 8E 1A
C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 02 31 00 C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 02 31 00
9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54
2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42
49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45
Figure 7: Hex Encoding of the Example Certificate. Figure 6: Hex Encoding of the Example Certificate.
Applying the SHA-256 hash function to the Certificate message, which Applying the SHA-256 hash function to the Certificate message, which
is starts with 0b 00 02 and ends with 9E 57 45, produces is starts with 0b 00 02 and ends with 9E 57 45, produces
0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af. 0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af.
Subsequently, this output is truncated to 32 bits, which leads to a
fingerprint of 0x086eefb4.
Authors' Addresses Authors' Addresses
Stefan Santesson Stefan Santesson
3xA Security AB 3xA Security AB
Scheelev. 17 Scheelev. 17
Lund 223 70 Lund 223 70
Sweden Sweden
Email: sts@aaa-sec.com Email: sts@aaa-sec.com
Hannes Tschofenig Hannes Tschofenig
ARM Ltd. ARM Ltd.
 End of changes. 30 change blocks. 
70 lines changed or deleted 53 lines changed or added

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