idnits 2.17.1 draft-ietf-tls-cached-info-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2015) is 3112 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 616 -- Looks like a reference, but probably isn't: '2' on line 641 -- Looks like a reference, but probably isn't: '3' on line 593 -- Looks like a reference, but probably isn't: '4' on line 617 == Missing Reference: 'ChangeCipherSpec' is mentioned on line 389, but not defined -- Looks like a reference, but probably isn't: '0' on line 613 ** Obsolete normative reference: RFC 4634 (Obsoleted by RFC 6234) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS S. Santesson 3 Internet-Draft 3xA Security AB 4 Intended status: Standards Track H. Tschofenig 5 Expires: April 21, 2016 ARM Ltd. 6 October 19, 2015 8 Transport Layer Security (TLS) Cached Information Extension 9 draft-ietf-tls-cached-info-20.txt 11 Abstract 13 Transport Layer Security (TLS) handshakes often include fairly static 14 information, such as the server certificate and a list of trusted 15 certification authorities (CAs). This information can be of 16 considerable size, particularly if the server certificate is bundled 17 with a complete certificate chain (i.e., the certificates of 18 intermediate CAs up to the root CA). 20 This document defines an extension that allows a TLS client to inform 21 a server of cached information, allowing the server to omit already 22 available information. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 21, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Cached Information Extension . . . . . . . . . . . . . . . . 3 61 4. Exchange Specification . . . . . . . . . . . . . . . . . . . 5 62 4.1. Server Certificate Message . . . . . . . . . . . . . . . 5 63 4.2. CertificateRequest Message . . . . . . . . . . . . . . . 6 64 5. Fingerprint Calculation . . . . . . . . . . . . . . . . . . . 7 65 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. New Entry to the TLS ExtensionType Registry . . . . . . . 10 69 8.2. New Registry for CachedInformationType . . . . . . . . . 10 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 73 10.2. Informative References . . . . . . . . . . . . . . . . . 12 74 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 77 1. Introduction 79 Reducing the amount of information exchanged during a Transport Layer 80 Security handshake to a minimum helps to improve performance in 81 environments where devices are connected to a network with a low 82 bandwidth, and lossy radio technology. With Internet of Things such 83 environments exist, for example, when devices use IEEE 802.15.4 or 84 Bluetooth Smart. For more information about the challenges with 85 smart object deployments please see [RFC6574]. 87 This specification defines a TLS extension that allows a client and a 88 server to exclude transmission information cached in an earlier TLS 89 handshake. 91 A typical example exchange may therefore look as follows. First, the 92 client and the server executes the full TLS handshake. The client 93 then caches the certificate provided by the server. When the TLS 94 client connects to the TLS server some time in the future, without 95 using session resumption, it then attaches the cached_info extension 96 defined in this document to the client hello message to indicate that 97 it had cached the certificate, and it provides the fingerprint of it. 98 If the server's certificate has not changed then the TLS server does 99 not need to send its' certificate and the corresponding certificate 100 chain again. In case information has changed, which can be seen from 101 the fingerprint provided by the client, the certificate payload is 102 transmitted to the client to allow the client to update the cache. 104 2. Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 This document refers to the TLS protocol but the description is 111 equally applicable to DTLS as well. 113 3. Cached Information Extension 115 This document defines a new extension type (cached_info(TBD)), which 116 is used in client hello and server hello messages. The extension 117 type is specified as follows. 119 enum { 120 cached_info(TBD), (65535) 121 } ExtensionType; 123 The extension_data field of this extension, when included in the 124 client hello, MUST contain the CachedInformation structure. The 125 client MAY send multiple CachedObjects of the same 126 CachedInformationType. This may, for example, be the case when the 127 client has cached multiple certificates from a server. 129 enum { 130 cert(1), cert_req(2) (255) 131 } CachedInformationType; 133 struct { 134 select (type) { 135 case client: 136 CachedInformationType type; 137 opaque hash_value<1..255>; 138 case server: 139 CachedInformationType type; 140 } body; 141 } CachedObject; 143 struct { 144 CachedObject cached_info<1..2^16-1>; 145 } CachedInformation; 147 This document defines the following two types: 149 'cert' Type for not sending the complete Server Certificate Message: 151 With the type field set to 'cert', the client MUST include the 152 fingerprint of the Certificate message in the hash_value field. 153 For this type the fingerprint MUST be calculated using the 154 procedure described in Section 5 with the Certificate message as 155 input data. 157 'cert_req' Type for not sending the complete CertificateRequest 158 Message: 160 With the type set to 'cert_req', the client MUST include the 161 fingerprint of the CertificateRequest message in the hash_value 162 field. For this type the fingerprint MUST be calculated using the 163 procedure described in Section 5 with the CertificateRequest 164 message as input data.. 166 New cached info types can be added following the policy described in 167 the IANA considerations section, see Section 8. New message digest 168 algorithms for use with these types can also be added by registering 169 a new type that makes use of the updated message digest algorithm. 170 There are no specific requirements for the use of specific hash 171 algorithms but for practical reason it is useful to re-use algorithms 172 already available with TLS ciphersuites to avoid additional code and 173 to keep the collision probably low. 175 4. Exchange Specification 177 Clients supporting this extension MAY include the "cached_info" 178 extension in the (extended) client hello. If the client includes the 179 extension then it MUST contain one or more CachedObject attributes. 181 A server supporting this extension MAY include the "cached_info" 182 extension in the (extended) server hello. By returning the 183 "cached_info" extension the server indicates that it supports the 184 cached info types. For each indicated cached info type the server 185 MUST alter the transmission of respective payloads, according to the 186 rules outlined with each type. If the server includes the extension 187 it MUST only include CachedObjects of a type also supported by the 188 client (as expressed in the client hello). For example, if a client 189 indicates support for 'cert' and 'cert_req' then the server cannot 190 respond with a "cached_info" attribute containing support for ('foo- 191 bar'. 193 Since the client includes a fingerprint of information it cached (for 194 each indicated type) the server is able to determine whether cached 195 information is stale. If the server supports this specification and 196 notices a mismatch between the data cached by the client and its own 197 information then the server MUST include the information in full and 198 MUST NOT list the respective type in the "cached_info" extension. 200 Note: If a server is part of a hosting environment then the client 201 may have cached multiple data items for a single server. To allow 202 the client to select the appropriate information from the cache it is 203 RECOMMENDED that the client utilizes the Server Name Indication 204 extension [RFC6066]. 206 Following a successful exchange of the "cached_info" extension in the 207 client and server hello, the server alters sending the corresponding 208 handshake message. How information is altered from the handshake 209 messages is defined in Section 4.1, and in Section 4.2 for the types 210 defined in this specification. 212 Appendix A shows an example hash calculation and Section 6 shows an 213 example protocol exchange. 215 4.1. Server Certificate Message 217 When a ClientHello message contains the "cached_info" extension with 218 a type set to 'cert' then the server MAY send the Certificate message 219 shown in Figure 1 under the following conditions: 221 o The server software implements the "cached_info" extension defined 222 in this specification. 224 o The 'cert' cached info extension is enabled (for example, a policy 225 allows the use of this extension). 227 o The server compared the value in the hash_value field of the 228 client-provided "cached_info" extension with the fingerprint of 229 the Certificate message it normally sends to clients. This check 230 ensures that the information cached by the client is current. The 231 procedure for calculating the fingerprint is described in 232 Section 5. 234 The original Certificate handshake message syntax is defined in RFC 235 5246 [RFC5246] and has been extended with RFC 7250 [RFC7250]. RFC 236 7250 allows the certificate payload to contain only the 237 SubjectPublicKeyInfo instead of the full information typically found 238 in a certificate. Hence, when this specification is used in 239 combination with [RFC7250] and the negotiated certificate type is a 240 raw public key then the TLS server omits sending a Certificate 241 payload that contains an ASN.1 Certificate structure with the 242 included SubjectPublicKeyInfo rather than the full certificate chain. 243 As such, this extension is compatible with the raw public key 244 extension defined in RFC 7250. 246 When the cached info specification is used then a modified version of 247 the Certificate message is exchanged. The modified structure is 248 shown in Figure 1. 250 struct { 251 opaque hash_value[1..255]; 252 } Certificate; 254 Figure 1: Cached Info Certificate Message. 256 4.2. CertificateRequest Message 258 When a fingerprint for an object of type 'cert_req' is provided in 259 the client hello, the server MAY send the CertificateRequest message 260 shown in Figure 2 message under the following conditions: 262 o The server software implements the "cached_info" extension defined 263 in this specification. 265 o The 'cert_req' cached info extension is enabled (for example, a 266 policy allows the use of this extension). 268 o The server compared the value in the hash_value field of the 269 client-provided "cached_info" extension with the fingerprint of 270 the CertificateRequest message it normally sends to clients. This 271 check ensures that the information cached by the client is 272 current. The procedure for calculating the fingerprint is 273 described in Section 5. 275 o The server wants to request a certificate from the client. 277 The original CertificateRequest handshake message syntax is defined 278 in RFC 5246 [RFC5246]. The modified structure of the 279 CertificateRequest message is shown in Figure 2. 281 struct { 282 opaque hash_value<1..255>; 283 } CertificateRequest; 285 Figure 2: Cached Info CertificateRequest Message. 287 The CertificateRequest payload is the input parameter to the 288 fingerprint calculation described in Section 5. 290 5. Fingerprint Calculation 292 The fingerprint MUST be computed as follows: 294 1. Compute the SHA-256 [RFC4634] hash of the input data. The input 295 data depends on the cached info type. This document defines two 296 cached info types, described in Section 4.1 and in Section 4.2. 297 Note that the computed hash only covers the input data structure 298 (and not any type and length information of the record layer). 300 2. Truncate the output of the SHA-256 hash. When a hash value is 301 truncated to 32 bits, the leftmost 32 bits (that is, the most 302 significant 32 bits in network byte order) from the binary 303 representation of the hash value MUST be used as the truncated 304 value. An example of a 256-bit hash output truncated to 32 bits 305 is shown in Figure 3. 307 256-bit hash: 308 0x265357902fe1b7e2a04b897c6025d7a2265357902fe1b7e2a04b897c6025d7a2 310 32-bit truncated hash: 311 0x26535790 313 Figure 3: Truncated Hash Example. 315 The purpose of the fingerprint provided by the client is to help the 316 server select the correct information. For example, in case of the 317 certificate message the fingerprint identifies the server certificate 318 (and the corresponding private key) for use for with the rest of the 319 handshake. Servers may have more than one certificate and therefore 320 a hash needs to be long enough to keep the probably of hash 321 collisions low. On the other hand, the cached info design aims to 322 reduce the amount of data being exchanged. The security of the 323 handshake depends on the private key and not on the size of the 324 fingerprint. Hence, the fingerprint is a way to prevent the server 325 from accidentally selecting the wrong information. If an attacker 326 injects an incorrect fingerprint then two outcomes are possible: (1) 327 The fingerprint does not relate to any cached state and the server 328 has to fall back to a full exchange. (2) If the attacker manages to 329 inject a fingerprint that refers to data the client has not cached 330 then the exchange will fail later when the client continues with the 331 handshake and aims to verify the digital signature. The signature 332 verification will fail since the public key cached by the client will 333 not correspond to the private key that was used by server to sign the 334 message. 336 6. Example 338 Figure 4 illustrates an example exchange using the TLS cached info 339 extension. In the normal TLS handshake exchange shown in flow (A) 340 the TLS server provides its certificate in the Certificate payload to 341 the client, see step [1]. This allows the client to store the 342 certificate for future use. After some time the TLS client again 343 interacts with the same TLS server and makes use of the TLS cached 344 info extension, as shown in flow (B). The TLS client indicates 345 support for this specification via the "cached_info" extension, see 346 [2], and indicates that it has stored the certificate from the 347 earlier exchange (by indicating the 'cert' type). With [3] the TLS 348 server acknowledges the supports of the 'cert' type and by including 349 the value in the server hello informs the client that the content of 350 the certificate payload contains the fingerprint of the certificate 351 instead of the RFC 5246-defined payload of the certificate message in 352 message [4]. 354 (A) Initial (full) Exchange 356 ClientHello -> 357 <- ServerHello 358 Certificate* // [1] 359 ServerKeyExchange* 360 CertificateRequest* 361 ServerHelloDone 363 Certificate* 364 ClientKeyExchange 365 CertificateVerify* 366 [ChangeCipherSpec] 367 Finished -> 369 <- [ChangeCipherSpec] 370 Finished 372 Application Data <-------> Application Data 374 (B) TLS Cached Extension Usage 376 ClientHello 377 cached_info=(cert) -> // [2] 378 <- ServerHello 379 cached_info=(cert) [3] 380 Certificate [4] 381 ServerKeyExchange* 382 ServerHelloDone 384 ClientKeyExchange 385 CertificateVerify* 386 [ChangeCipherSpec] 387 Finished -> 389 <- [ChangeCipherSpec] 390 Finished 392 Application Data <-------> Application Data 394 Figure 4: Example Message Exchange 396 7. Security Considerations 398 This specification defines a mechanism to reference stored state 399 using a fingerprint. Sending a fingerprint of cached information in 400 an unencrypted handshake, as the client and server hello is, may 401 allow an attacker or observer to correlate independent TLS exchanges. 402 While some information elements used in this specification, such as 403 server certificates, are public objects and usually do not contain 404 sensitive information, other not yet defined types may. Those who 405 implement and deploy this specification should therefore make an 406 informed decision whether the cached information is inline with their 407 security and privacy goals. In case of concerns, it is advised to 408 avoid sending the fingerprint of the data objects in clear. 410 The use of the cached info extension allows the server to send 411 significantly smaller TLS messages. Consequently, these omitted 412 parts of the messages are not included in the transcript of the 413 handshake in the TLS Finish message. However, since the client and 414 the server communicate the hash values of the cached data in the 415 initial handshake messages the fingerprints are included in the TLS 416 Finish message. 418 Clients MUST ensure that they only cache information from legitimate 419 sources. For example, when the client populates the cache from a TLS 420 exchange then it must only cache information after the successful 421 completion of a TLS exchange to ensure that an attacker does not 422 inject incorrect information into the cache. Failure to do so allows 423 for man-in-the-middle attacks. 425 Security consideratios for the fingerprint calculation are discussed 426 in Section 5. 428 8. IANA Considerations 430 8.1. New Entry to the TLS ExtensionType Registry 432 IANA is requested to add an entry to the existing TLS ExtensionType 433 registry, defined in RFC 5246 [RFC5246], for cached_info(TBD) defined 434 in this document. 436 8.2. New Registry for CachedInformationType 438 IANA is requested to establish a registry for TLS 439 CachedInformationType values. The first entries in the registry are 441 o cert(1) 443 o cert_req(2) 445 The policy for adding new values to this registry, following the 446 terminology defined in RFC 5226 [RFC5226], is as follows: 448 o 0-63 (decimal): Standards Action 449 o 64-223 (decimal): Specification Required 451 o 224-255 (decimal): reserved for Private Use 453 9. Acknowledgments 455 We would like to thank the following persons for your detailed 456 document reviews: 458 o Paul Wouters and Nikos Mavrogiannopoulos (December 2011) 460 o Rob Stradling (February 2012) 462 o Ondrej Mikle (in March 2012) 464 o Ilari Liusvaara, Adam Langley, and Eric Rescorla (in July 2014) 466 o Sean Turner (in August 2014) 468 o Martin Thomson (in August 2015) 470 We would also to thank Martin Thomson, Karthikeyan Bhargavan, Sankalp 471 Bagaria and Eric Rescorla for their feedback regarding the 472 fingerprint calculation. 474 Finally, we would like to thank the TLS working group chairs, Sean 475 Turner and Joe Salowey, as well as the responsible security area 476 director, Stephen Farrell, for their support. 478 10. References 480 10.1. Normative References 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 484 RFC2119, March 1997, 485 . 487 [RFC4634] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 488 (SHA and HMAC-SHA)", RFC 4634, DOI 10.17487/RFC4634, July 489 2006, . 491 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 492 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 493 RFC5246, August 2008, 494 . 496 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 497 Extensions: Extension Definitions", RFC 6066, DOI 498 10.17487/RFC6066, January 2011, 499 . 501 10.2. Informative References 503 [ASN.1-Dump] 504 Gutmann, P., "ASN.1 Object Dump Program", February 2013, 505 . 507 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 508 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 509 DOI 10.17487/RFC5226, May 2008, 510 . 512 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 513 Workshop", RFC 6574, DOI 10.17487/RFC6574, April 2012, 514 . 516 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 517 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 518 Transport Layer Security (TLS) and Datagram Transport 519 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 520 June 2014, . 522 Appendix A. Example 524 Consider a certificate containing an NIST P256 elliptic curve public 525 key displayed using Peter Gutmann's ASN.1 decoder [ASN.1-Dump] in 526 Figure 5. 528 0 556: SEQUENCE { 529 4 434: SEQUENCE { 530 8 3: [0] { 531 10 1: INTEGER 2 532 : } 533 13 1: INTEGER 13 534 16 10: SEQUENCE { 535 18 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 536 : } 537 28 62: SEQUENCE { 538 30 11: SET { 539 32 9: SEQUENCE { 540 34 3: OBJECT IDENTIFIER countryName (2 5 4 6) 541 39 2: PrintableString 'NL' 542 : } 543 : } 544 43 17: SET { 545 45 15: SEQUENCE { 546 47 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 547 52 8: PrintableString 'PolarSSL' 548 : } 549 : } 550 62 28: SET { 551 64 26: SEQUENCE { 552 66 3: OBJECT IDENTIFIER commonName (2 5 4 3) 553 71 19: PrintableString 'Polarssl Test EC CA' 554 : } 555 : } 556 : } 557 92 30: SEQUENCE { 558 94 13: UTCTime 24/09/2013 15:52:04 GMT 559 109 13: UTCTime 22/09/2023 15:52:04 GMT 560 : } 561 124 65: SEQUENCE { 562 126 11: SET { 563 128 9: SEQUENCE { 564 130 3: OBJECT IDENTIFIER countryName (2 5 4 6) 565 135 2: PrintableString 'NL' 566 : } 567 : } 568 139 17: SET { 569 141 15: SEQUENCE { 570 143 3: OBJECT IDENTIFIER organizationName (2 5 4 10) 571 148 8: PrintableString 'PolarSSL' 572 : } 573 : } 574 158 31: SET { 575 160 29: SEQUENCE { 576 162 3: OBJECT IDENTIFIER commonName (2 5 4 3) 577 167 22: PrintableString 'PolarSSL Test Client 2' 578 : } 579 : } 580 : } 581 191 89: SEQUENCE { 582 193 19: SEQUENCE { 583 195 7: OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1) 584 204 8: OBJECT IDENTIFIER prime256v1 (1 2 840 10045 3 1 7) 585 : } 586 214 66: BIT STRING 587 : 04 57 E5 AE B1 73 DF D3 AC BB 93 B8 81 FF 12 AE 588 : EE E6 53 AC CE 55 53 F6 34 0E CC 2E E3 63 25 0B 589 : DF 98 E2 F3 5C 60 36 96 C0 D5 18 14 70 E5 7F 9F 590 : D5 4B 45 18 E5 B0 6C D5 5C F8 96 8F 87 70 A3 E4 591 : C7 592 : } 593 282 157: [3] { 594 285 154: SEQUENCE { 595 288 9: SEQUENCE { 596 290 3: OBJECT IDENTIFIER basicConstraints (2 5 29 19) 597 295 2: OCTET STRING, encapsulates { 598 297 0: SEQUENCE {} 599 : } 600 : } 601 299 29: SEQUENCE { 602 301 3: OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14) 603 306 22: OCTET STRING, encapsulates { 604 308 20: OCTET STRING 605 : 7A 00 5F 86 64 FC E0 5D E5 11 10 3B B2 E6 3B C4 606 : 26 3F CF E2 607 : } 608 : } 609 330 110: SEQUENCE { 610 332 3: OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35) 611 337 103: OCTET STRING, encapsulates { 612 339 101: SEQUENCE { 613 341 20: [0] 614 : 9D 6D 20 24 49 01 3F 2B CB 78 B5 19 BC 7E 24 C9 615 : DB FB 36 7C 616 363 66: [1] { 617 365 64: [4] { 618 367 62: SEQUENCE { 619 369 11: SET { 620 371 9: SEQUENCE { 621 373 3: OBJECT IDENTIFIER countryName (2 5 4 6) 622 378 2: PrintableString 'NL' 623 : } 624 : } 625 382 17: SET { 626 384 15: SEQUENCE { 627 386 3: OBJECT IDENTIFIER organizationName 628 : (2 5 4 10) 629 391 8: PrintableString 'PolarSSL' 630 : } 631 : } 632 401 28: SET { 633 403 26: SEQUENCE { 634 405 3: OBJECT IDENTIFIER commonName (2 5 4 3) 635 410 19: PrintableString 'Polarssl Test EC CA' 636 : } 637 : } 638 : } 639 : } 640 : } 641 431 9: [2] 00 C1 43 E2 7E 62 43 CC E8 642 : } 643 : } 644 : } 645 : } 646 : } 647 : } 648 442 10: SEQUENCE { 649 444 8: OBJECT IDENTIFIER ecdsaWithSHA256 (1 2 840 10045 4 3 2) 650 : } 651 454 104: BIT STRING, encapsulates { 652 457 101: SEQUENCE { 653 459 48: INTEGER 654 : 4A 65 0D 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D 655 : BB 70 4C 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 656 : 65 8E 1A C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 657 509 49: INTEGER 658 : 00 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 659 : 54 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 660 : 42 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 661 : 45 662 : } 663 : } 664 : } 666 Figure 5: ASN.1-based Certificate: Example. 668 To include the certificate shown in Figure 5 in a TLS/DTLS 669 Certificate message it is prepended with a message header. This 670 Certificate message header in our example is 0b 00 02 36 00 02 33 00 671 02 00 02 30, which indicates: 673 Message Type: 0b -- 1 byte type field indicating a Certificate 674 message 676 Length: 00 02 36 -- 3 byte length field indicating a 566 bytes 677 payload 679 Certificates Length: 00 02 33 -- 3 byte length field indicating 563 680 bytes for the entire certificates_list structure, which may 681 contain multiple certificates. In our example only one 682 certificate is included. 684 Certificate Length: 00 02 30 -- 3 byte length field indicating 560 685 bytes of the actual certificate following immediately afterwards. 687 In our example, this is the certificate content with 30 82 02 .... 688 9E 57 45 shown in Figure 6. 690 The hex encoding of the ASN.1 encoded certificate payload shown in 691 Figure 5 leads to the following encoding. 693 30 82 02 2C 30 82 01 B2 A0 03 02 01 02 02 01 0D 694 30 0A 06 08 2A 86 48 CE 3D 04 03 02 30 3E 31 0B 695 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 696 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1C 697 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 72 73 73 698 6C 20 54 65 73 74 20 45 43 20 43 41 30 1E 17 0D 699 31 33 30 39 32 34 31 35 35 32 30 34 5A 17 0D 32 700 33 30 39 32 32 31 35 35 32 30 34 5A 30 41 31 0B 701 30 09 06 03 55 04 06 13 02 4E 4C 31 11 30 0F 06 702 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 4C 31 1F 703 30 1D 06 03 55 04 03 13 16 50 6F 6C 61 72 53 53 704 4C 20 54 65 73 74 20 43 6C 69 65 6E 74 20 32 30 705 59 30 13 06 07 2A 86 48 CE 3D 02 01 06 08 2A 86 706 48 CE 3D 03 01 07 03 42 00 04 57 E5 AE B1 73 DF 707 D3 AC BB 93 B8 81 FF 12 AE EE E6 53 AC CE 55 53 708 F6 34 0E CC 2E E3 63 25 0B DF 98 E2 F3 5C 60 36 709 96 C0 D5 18 14 70 E5 7F 9F D5 4B 45 18 E5 B0 6C 710 D5 5C F8 96 8F 87 70 A3 E4 C7 A3 81 9D 30 81 9A 711 30 09 06 03 55 1D 13 04 02 30 00 30 1D 06 03 55 712 1D 0E 04 16 04 14 7A 00 5F 86 64 FC E0 5D E5 11 713 10 3B B2 E6 3B C4 26 3F CF E2 30 6E 06 03 55 1D 714 23 04 67 30 65 80 14 9D 6D 20 24 49 01 3F 2B CB 715 78 B5 19 BC 7E 24 C9 DB FB 36 7C A1 42 A4 40 30 716 3E 31 0B 30 09 06 03 55 04 06 13 02 4E 4C 31 11 717 30 0F 06 03 55 04 0A 13 08 50 6F 6C 61 72 53 53 718 4C 31 1C 30 1A 06 03 55 04 03 13 13 50 6F 6C 61 719 72 73 73 6C 20 54 65 73 74 20 45 43 20 43 41 82 720 09 00 C1 43 E2 7E 62 43 CC E8 30 0A 06 08 2A 86 721 48 CE 3D 04 03 02 03 68 00 30 65 02 30 4A 65 0D 722 7B 20 83 A2 99 B9 A8 0F FC 8D EE 8F 3D BB 70 4C 723 96 03 AC 8E 78 70 DD F2 0E A0 B2 16 CB 65 8E 1A 724 C9 3F 2C 61 7E F8 3C EF AD 1C EE 36 20 02 31 00 725 9D F2 27 A6 D5 74 B8 24 AE E1 6A 3F 31 A1 CA 54 726 2F 08 D0 8D EE 4F 0C 61 DF 77 78 7D B4 FD FC 42 727 49 EE E5 B2 6A C2 CD 26 77 62 8E 28 7C 9E 57 45 729 Figure 6: Hex Encoding of the Example Certificate. 731 Applying the SHA-256 hash function to the Certificate message, which 732 is starts with 0b 00 02 and ends with 9E 57 45, produces 733 0x086eefb4859adfe977defac494fff6b73033b4ce1f86b8f2a9fc0c6bf98605af. 735 Subsequently, this output is truncated to 32 bits, which leads to a 736 fingerpint of 0x086eefb4. 738 Authors' Addresses 740 Stefan Santesson 741 3xA Security AB 742 Scheelev. 17 743 Lund 223 70 744 Sweden 746 Email: sts@aaa-sec.com 748 Hannes Tschofenig 749 ARM Ltd. 750 Hall in Tirol 6060 751 Austria 753 Email: Hannes.tschofenig@gmx.net 754 URI: http://www.tschofenig.priv.at